MySQL (4) principio de transacción y análisis

Artículos de la serie MySQL

MySQL (1) Estructura básica, operación de instrucciones SQL, pruebe
MySQL (2) Principio y optimización de indexación
MySQL (3) Optimización SQL, grupo de búfer, búfer de cambio
MySQL (4) Principio y análisis de transacciones
MySQL (5) Estrategia de almacenamiento en caché
MySQL (6) Tres paradigmas de la base de datos de replicación maestro-esclavo



prefacio

Antecedentes : como se mencionó anteriormente, MySQL puede operar simultáneamente, es decir, varios clientes MySQL operan la base de datos en un servidor, por lo que implica el problema del acceso concurrente, por lo que existe el concepto de transacción.


Definición : La esencia de una transacción es la unidad de control de concurrencia, que es una colección de una serie de operaciones de base de datos definidas por los usuarios. Estas operaciones se realizan o no se realizan, y son una unidad de trabajo indivisible.


Composición : una transacción puede estar compuesta por una declaración SQL muy simple o un conjunto de declaraciones SQL complejas; en MySQL innodb, una sola declaración tiene una transacción; puede configurar la sesión actual para que se confirme manualmente mediante autocommit = 0;

Las transacciones tienen propiedades ACID, a saber, atomicidad, consistencia, aislamiento y durabilidad.

Propiedades del ÁCIDO

Atomicidad (A)

Las operaciones de transacción se realizan (commit) o ​​no se realizan (rollback); una transacción es una unidad de ejecución de programa que accede y actualiza varios elementos de datos en la base de datos, y es una unidad de trabajo indivisible; la operación de reversión se implementa a través de undolog. El undolog registra las operaciones específicas de cada paso de la transacción, cuando se retrotrae, reproducirá la operación inversa de las operaciones específicas de la transacción, todas las
operaciones incluidas en la transacción son un todo indivisible, ya sean todas ejecutadas o no. ejecutado en absoluto;

Aunque se dice que las transacciones deben mantener la atomicidad, por ejemplo, la ejecución en serie completa puede asegurar la atomicidad de la ejecución de instrucciones en las transacciones; pero el rendimiento de este método es muy bajo, por lo que Mysql suele utilizar la ejecución cruzada de instrucciones entre transacciones para mejorar el rendimiento. .

aislamiento (yo)

Descripción: El grado de influencia mutua entre varias transacciones ; previene la inconsistencia de datos causada por la ejecución cruzada de múltiples transacciones concurrentes, a través de bloqueos y MVCC.
Propósito: Estipula principalmente que múltiples transacciones acceden al mismo recurso de datos, y el comportamiento de cada transacción que accede al recurso de datos.Diferente aislamiento es para hacer frente a diferentes fenómenos (lectura sucia, lectura no repetible, lectura fantasma); el aislamiento de transacciones requiere
cada Los objetos de las transacciones de lectura y escritura se pueden separar de los objetos de operación de otras transacciones, y las transacciones concurrentes no se afectarán entre sí. Se establecen diferentes grados de niveles de aislamiento, y el rendimiento se puede mejorar rompiendo moderadamente la consistencia; realizado por MVCC y bloqueos; MVCC es un control de concurrencia de varias versiones, que resuelve principalmente el problema de las lecturas consistentes sin bloqueo y logra un rendimiento de lectura concurrente eficiente al registrar y obtener versiones de fila en lugar de usar bloqueos para restringir las operaciones de lectura. Los bloqueos se utilizan para manejar operaciones DML concurrentes; la base de datos proporciona una estrategia de bloqueos granulares, que se bloquean en tres granularidades: tablas (árbol de índice B+ agrupado), páginas (nodos de hoja de árbol de índice B+ agrupado) y filas (un segmento de registro). filas en nodos hoja);

Persistencia (D)

Una vez completada la transacción, se deben registrar los cambios realizados en los datos, incluido el almacenamiento de datos y la copia de seguridad de la red de copias múltiples;
después de que se confirme la transacción, las operaciones de adición, eliminación y modificación de la transacción serán persistentes (el desplazamiento de página el valor escrito en el archivo de disco redolog son datos específicos); incluso si ocurren fallas como tiempo de inactividad, la base de datos puede restaurar los datos. Redolog registra registros físicos;

Consistencia (C)

Antes y después de la transacción, todos los datos mantienen un estado coherente, que no puede violar la verificación de coherencia de datos (verificación de restricción de integridad); la
coherencia significa que la transacción cambia la base de datos de un estado coherente al siguiente estado coherente, antes y después de la ejecución de la transacción, las restricciones de integridad de la base de datos no se violan; una unidad de transacción debe confirmarse antes de que sea visible para otras transacciones. Por ejemplo: el nombre de una tabla es una clave única, si una transacción modifica el nombre, pero después de confirmar o revertir la transacción, el nombre de la tabla deja de ser único, lo que rompe la consistencia; la consistencia está determinada por la atomicidad El aislamiento y la persistencia se mantienen conjuntamente.

nivel de aislamiento

Cuando se ejecutan múltiples transacciones al mismo tiempo, es necesario considerar el nivel de aislamiento, es decir, aislamiento diferente. Los estándares ISO y ANIS SQL se estandarizan en cuatro niveles de aislamiento de transacciones, cuanto mayor sea el nivel de aislamiento, menor será el rendimiento .
Es decir, los primeros tres niveles de aislamiento de LECTURA NO COMPROMETIDA, LECTURA COMPROMETIDA, LECTURA REPETIBLE y SERIALIZABLE provocarán diferentes excepciones de lectura simultáneas, a saber , escenarios de lectura sucia, lectura no repetible y lectura fantasma .


Diferentes excepciones de lectura concurrentes generadas por diferentes niveles de aislamiento:
lectura sucia : una transacción lee datos modificados por otra transacción no confirmada;
lectura no repetible : una transacción lee los mismos datos dos veces;
lectura fantasma : una transacción Los conjuntos de resultados obtenidos al leer los registros en el mismo rango dos veces en el mismo rango son diferentes;

La diferencia entre
las lecturas sucias y las lecturas no repetibles es que las lecturas sucias leen datos no confirmados de otra transacción, mientras que las lecturas no repetibles leen modificaciones después de que se confirme otra transacción; esencialmente, todas son modificadas por otras transacciones La lectura de esta transacción;
no la lectura repetible y la lectura fantasma son similares; la lectura no repetible es leer el mismo registro dos veces y obtener resultados diferentes; la lectura fantasma se obtiene leyendo los registros en el mismo rango dos veces Los conjuntos de resultados son diferentes (el número puede ser diferente, o el mismo número puede ser diferente, por ejemplo, se agrega una nueva fila después de una fila de x); la lectura no repetible se debe a que otras transacciones han realizado una operación de actualización, y la lectura fantasma se debe a que otras transacciones han realizado una inserción o eliminación operación.


El nivel de aislamiento predeterminado admitido por MySQL innodb es LECTURA REPETIBLE;

LEER SIN COMPROMISO

Lectura no confirmada; las operaciones de lectura en este nivel no se bloquean, las operaciones de escritura agregan bloqueos exclusivos y los bloqueos de escritura se liberan después de que las transacciones se confirman o revierten; por lo tanto, los datos antes de las reversiones de transacciones pueden leerse, lo que resulta en lecturas sucias.

LEER COMPROMETIDO

Lectura confirmada (RC); bajo este nivel de aislamiento, se leen los datos más recientes de la versión histórica, por lo que se leen los datos confirmados; se produce una lectura no repetible.

LECTURA REPETIBLE

Lectura repetible (RR); en este momento, la operación de lectura lee los datos de la versión al comienzo de la transacción; se producirá una lectura fantasma. Puede usar la lectura actual, es decir, bloquear la lectura para resolver el fenómeno de lectura fantasma.

SERIALIZABLE

Serializable; en este nivel, se agrega un bloqueo compartido a la lectura; por lo que las transacciones se ejecutan en serie; en este momento, el nivel de aislamiento es el más estricto;

bloqueo compartido y bloqueo exclusivo

Para resolver el problema de las excepciones de lectura simultáneas, la base de datos introduce un mecanismo de bloqueo. Los bloqueos se dividen en bloqueos compartidos y bloqueos exclusivos. Los bloqueos compartidos permiten que varias transacciones lean los mismos datos al mismo tiempo, pero no pueden modificarlos; los bloqueos exclusivos solo permiten que una transacción modifique los datos.

MVCC

MVCC es una tecnología de control de concurrencia de varias versiones que se puede usar para resolver excepciones de lectura simultánea y lecturas fantasma sin bloqueo . MVCC logra el aislamiento creando una versión separada para cada transacción, cada versión contiene todos los datos que vio la transacción mientras se ejecutaba. Cuando varias transacciones acceden a los mismos datos al mismo tiempo, el sistema juzgará si permite el acceso según el número de versión de cada transacción.

La versión múltiple se basa principalmente en el registro de deshacer para lograrlo, mientras que el control de concurrencia se logra a través del campo oculto de la tabla + instantánea de ReadView

Para obtener más información, consulte: https://maimai.cn/article/detail?fid=1760762705&efid=UVf-Pw63L4lRkESvTUv1AQ

vista de lectura

Bajo los niveles de aislamiento de lectura confirmada y lectura repetible, MVCC usa la vista de lectura para implementar. La diferencia entre ellos es que el tiempo de creación de la vista de lectura es diferente:

El nivel de aislamiento de lectura confirmada generará una nueva vista de lectura para cada selección en una transacción, lo que también significa que leer el mismo dato varias veces en la misma transacción puede causar inconsistencia en los datos; hay una situación de lectura no repetible. Debido a que otras transacciones pueden modificar el registro y enviarlo durante lecturas múltiples, el
nivel de aislamiento repetible de lectura es generar una vista de lectura cuando se inicia la transacción y usar esta vista de lectura solo cuando los datos se leen en toda la transacción, lo que garantiza que Los datos leídos durante la transacción son todos los registros antes de que comience la transacción, lo que resuelve el problema de la lectura no repetible.

rehacer

El registro de rehacer se usa para lograr la persistencia de la transacción; la memoria contiene el búfer de registro de rehacer y el disco contiene el archivo de registro de rehacer;
cuando se confirma la transacción, todos los registros de la transacción deben escribirse primero en el registro de rehacer archivo para la persistencia.La operación de confirmación de la transacción se completa antes de que se confirme la transacción;
el registro de rehacer se escribe secuencialmente, registrando la modificación de cada página (página, desplazamiento de página y contenido modificado); no hay necesidad de editar el redo archivo de registro cuando la base de datos se está ejecutando Realice operaciones de lectura; solo cuando ocurra un tiempo de inactividad, se usará el registro de rehacer para la recuperación;

deshacer

El registro de deshacer se usa para ayudar a la reversión de transacciones y la función MVCC; se almacena en el espacio de tabla compartido; deshacer es un registro lógico, que restaura lógicamente la base de datos a su estado original al revertir y realiza la operación inversa anterior de acuerdo con el deshacer registros; por ejemplo, si hay una operación de inserción en la transacción, ejecute la operación de eliminación; para la operación de actualización, realice la operación de actualización opuesta; al mismo tiempo,
el registro de deshacer registra la información de la versión de la fila, que se utiliza para procesar la función MVCC;

Supongo que te gusta

Origin blog.csdn.net/weixin_44477424/article/details/131741487
Recomendado
Clasificación