1. En MySQL, el soporte de transacciones se implementa en la capa del motor. MySQL es un sistema que admite múltiples motores, pero el motor MyISAM nativo de MySQL no admite transacciones, que es una de las razones importantes por las que MyISAM fue reemplazado por InnoDB.
2. Características de la transacción: ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad, a saber, atomicidad, consistencia, aislamiento, durabilidad). Actualmente, InnoDB se usa principalmente como un ejemplo para discutir el "aislamiento".
3. Cuando se ejecutan varias transacciones en la base de datos al mismo tiempo, puede haber problemas de lectura sucia (lectura sucia), lectura no repetible (lectura no repetible), lectura fantasma (lectura fantasma). El concepto de "nivel de aislamiento". Cuanto más estricto es el aislamiento, menor es la eficiencia. Muchas veces, tenemos que encontrar un equilibrio entre los dos.
4. Los niveles de aislamiento de transacciones estándar de SQL incluyen: lectura no confirmada, lectura confirmada, lectura repetible y serializable:
- Leer no confirmado significa que cuando una transacción no se ha confirmado, los cambios realizados pueden verse en otras transacciones.
- Leer confirmación significa que después de que se confirma una transacción, los cambios que realice serán vistos por otras transacciones.
- La lectura repetible significa que los datos vistos durante la ejecución de una transacción son siempre los mismos que se ven cuando se inicia la transacción. Por supuesto, bajo el nivel de aislamiento de lectura repetible, los cambios no confirmados también son invisibles para otras transacciones.
- La serialización, como su nombre lo indica, para la misma fila de registros, "escribir" agregará "bloqueo de escritura", "leer" agregará "bloqueo de lectura". Cuando hay un conflicto de bloqueo de lectura y escritura, la transacción a la que se accede más tarde debe esperar a que se complete la transacción anterior antes de que pueda continuar.
Supongamos que solo hay una columna en la tabla de datos T, y el valor de una fila es 1, el siguiente es el comportamiento de ejecutar dos transacciones en orden cronológico.
mysql> crear tabla T (c int ) engine = InnoDB; insertar en T (c) valores ( 1 );
¿Cuáles son los diferentes resultados de retorno de la transacción A bajo diferentes niveles de aislamiento, es decir, cuáles son los valores de retorno de V1, V2 y V3 en la figura?
- Si el nivel de aislamiento es "lectura no confirmada", el valor de V1 es 2. En este momento, aunque la transacción B no se ha enviado, el resultado ha sido visto por A. Por lo tanto, tanto V2 como V3 también son 2.
- Si el nivel de aislamiento es "lectura de confirmación", entonces V1 es 1 y V2 es 2. La actualización de la transacción B solo puede ser vista por A después de la confirmación. Por lo tanto, el valor de V3 también es 2.
- Si el nivel de aislamiento es "lectura repetible", V1 y V2 son 1 y V3 es 2. La razón por la cual V2 sigue siendo 1 es para seguir este requisito: los datos vistos por la transacción durante la ejecución deben ser consistentes antes y después.
- Si el nivel de aislamiento es "serialización", se bloqueará cuando la transacción B ejecute "cambio 1 a 2". Hasta que se confirme la transacción A, la transacción B puede continuar ejecutándose. Entonces, desde la perspectiva de A, los valores de V1 y V2 son 1, y el valor de V3 es 2.
El nivel de aislamiento predeterminado de la base de datos Oracle es en realidad "confirmación de lectura", por lo que para algunas aplicaciones que migran de Oracle a MySQL, para garantizar la coherencia del nivel de aislamiento de la base de datos, debe recordar establecer el nivel de aislamiento de MySQL para "confirmación de lectura". Método de configuración: use show variables para ver el valor actual; establezca el valor del parámetro de inicio transacción-aislamiento en READ-COMMITTED;
mysql> muestra variables como ' transaction_isolation ' ;
5. No se recomienda usar transacciones largas: (no entiendo muy bien aquí)
Las transacciones largas significan que habrá una vista muy antigua de las transacciones en el sistema. Debido a que estas transacciones pueden acceder a cualquier información en la base de datos en cualquier momento, antes de que se confirme esta transacción, los registros de reversión que puede usar en la base de datos deben conservarse, lo que resultará en una gran cantidad de espacio de almacenamiento ocupado; además del impacto en el segmento de reversión Las transacciones también ocupan recursos de bloqueo y pueden arrastrar hacia abajo toda la biblioteca.
6. Los métodos de inicio de transacciones de MySQL son los siguientes:
-
Inicie explícitamente una declaración de transacción, comience o inicie la transacción. La declaración de confirmación de respaldo es commit y la declaración de reversión es rollback.
-
set autocommit = 0, este comando desactivará el envío automático de este hilo. Esto significa que si solo ejecuta una instrucción select, la transacción comenzará y no se confirmará automáticamente. Esta transacción continúa hasta que ejecute activamente una declaración de confirmación o reversión, o desconecte.
Algunos marcos de conexión de cliente ejecutarán un comando set autocommit = 0 después de que la conexión predeterminada sea exitosa. Esto lleva a las siguientes consultas en la transacción, si es una conexión larga, conduce a una transacción larga inesperada.
Por lo tanto, se recomienda usar set autocommit = 1 para iniciar una transacción a través de una declaración explícita.
Pero para una empresa que requiere el uso frecuente de transacciones, el segundo método no necesita ejecutar activamente un "comienzo" al comienzo de cada transacción, lo que reduce el número de interacciones de los estados de cuenta. Entonces, si tiene problemas con el problema de "una interacción más", se recomienda utilizar el trabajo de compromiso y la sintaxis de la cadena. En el caso de la confirmación automática es 1, la transacción comenzó explícitamente con begin, confirme la transacción si se ejecuta la confirmación. Si se ejecuta el trabajo de compromiso y la cadena, la transacción se confirma y la siguiente transacción se inicia automáticamente, lo que también ahorra la sobrecarga de ejecutar nuevamente la instrucción de inicio. Al mismo tiempo, el beneficio es saber claramente si cada declaración está en una transacción desde la perspectiva del desarrollo del programa.
Puede consultar transacciones largas en la tabla innodb_trx de la biblioteca information_schema. Por ejemplo, la siguiente instrucción se utiliza para buscar transacciones con una duración de más de 60 s.
seleccione * de information_schema.innodb_trx donde TIME_TO_SEC (timediff (now (), trx_started))> 60