La eficiencia de las consultas de Mysql es tan alta que resultó ser así (MVCC es muy simple de entender)

Mecanismo de control de concurrencia de múltiples versiones MVCC

La misma instrucción de consulta SQL se ejecuta varias veces en una transacción. El resultado de la consulta es el mismo. Incluso si otras transacciones modifican los datos, no afectará los resultados de la consulta de la instrucción SQL de la transacción actual. ¿Cómo lo hacen estos Mysql?

¿Cómo garantiza Mysql un alto aislamiento de transacciones bajo el nivel de aislamiento de lectura repetible (nivel predeterminado)?

El aislamiento de Mysql está garantizado por el mecanismo MVCC (Multi-Version Concurrency Control). Por defecto, las operaciones de lectura y escritura de una fila de datos no asegurarán el aislamiento por bloqueo y exclusión mutua, evitando bloqueos frecuentes y exclusión mutua. Y para garantizar un mayor aislamiento en el nivel de aislamiento serializado, todas las operaciones están bloqueadas y se excluyen mutuamente . Mysql implementa el mecanismo MVCC en niveles de aislamiento de lectura enviados y repetibles .

Explicación detallada de la cadena de versiones de registro de deshacer y el mecanismo de vista de lectura

La cadena de versión del registro de deshacer significa que después de que una fila de datos ha sido modificada por múltiples transacciones sucesivamente, después de que se modifica cada transacción, Mysql retendrá el registro de reversión de deshacer de los datos antes de la modificación y usará dos campos ocultos trx_id (id de transacción) y roll_pointer ( Puntero rodante) conectan estos registros de deshacer en serie para formar una cadena de versiones de registros históricos.

Inserte la descripción de la imagen aquí
Bajo el nivel de aislamiento de lectura repetible , cuando la transacción está activada, la única vista de lectura de la transacción actual se generará cuando se ejecute cualquier consulta SQL , y la vista no cambiará antes del final de la transacción (si se lee el nivel de aislamiento comprometido en cada ejecución Se volverá a generar al consultar sql), esta vista se compone de todas las matrices de ID de transacción no confirmadas (la ID más pequeña en la matriz es min_id) y la ID de transacción más grande (max_id) creada cuando se ejecuta la consulta . Cualquier consulta SQL que dé como resultado la transacción debe obtenerse de Los datos más recientes de la cadena de versiones correspondiente se comparan con la vista de lectura uno por uno para obtener el resultado final. Reglas de comparación de la cadena de versiones:

  1. Si el trx_id de la fila cae en la parte verde (trx_id <min_id), significa que esta versión es generada por la transacción comprometida, y estos datos son visibles;
  2. Si el trx_id de la fila cae en la parte roja (trx_id> max_id), significa que esta versión es generada por la transacción iniciada en el futuro y es invisible (si
    el trx_id de la fila es la propia transacción actual es visible);
  3. Si el trx_id de la fila cae en la parte amarilla (min_id <= trx_id <= max_id), hay dos casos
  • Si el trx_id de la fila está en la matriz de vista, significa que esta versión es generada por una transacción que aún no ha sido confirmada y no es visible (si el trx_id de la fila es la propia transacción actual es visible);
  • Si el trx_id de la fila no está en la matriz de vista, significa que esta versión es generada por la transacción que se ha enviado y está visible.

Para el caso de eliminación, se puede considerar como un caso especial de actualización. Se copiarán los últimos datos de la cadena de versiones y trx_id se modificará al
trx_id de la operación de eliminación . Al mismo tiempo, el (deleted_flag) en el encabezado del registro del registro ) Escriba verdadero en el bit de bandera para indicar que el registro actual ha sido
eliminado. Al consultar el registro correspondiente de acuerdo con las reglas anteriores, si el bit de bandera delete_flag es verdadero, significa que el registro ha sido eliminado y no se devuelven datos
.

Nota : El comando begin / start transaction no es el punto de partida de una transacción. Después de ejecutar la primera instrucción para modificar la tabla InnoDB después de que se ejecutan, la transacción se inicia realmente y luego la identificación de la transacción se aplicará a mysql. MySQL sigue estrictamente la transacción Iniciar orden para asignar ID de transacción.

Resumen:
La realización del mecanismo MVCC es a través del mecanismo de lectura-vista y el mecanismo de comparación de la cadena de versiones deshacer, de modo que diferentes transacciones leerán diferentes versiones de los mismos datos en la cadena de versiones de acuerdo con las reglas de comparación de la cadena de versiones de datos.

Supongo que te gusta

Origin blog.csdn.net/weixin_51049616/article/details/108789681
Recomendado
Clasificación