Escribí un artículo anteriormente y compartí con ustedes que MySQL implica un control de concurrencia de versiones múltiples de MVCC de punto de conocimiento. No entiendo este problema, siempre siento que falta algo. Así que hoy quiero tomarme un momento para hablarles sobre MVCC.

Para comprender MVCC, es mejor comprender primero el nivel de aislamiento de las transacciones en InnoDB; de lo contrario, es difícil comprender MVCC simplemente observando el concepto.

1. Nivel de aislamiento

1.1 Teoría

Hay cuatro niveles de aislamiento de las transacciones intermedias de MySQL, de la siguiente manera:

Serialización (SERIALIZABLE)
LECTURA REPETIBLE
LEER COMPROMETIDO
LEER SIN COMPROMISO

Los cuatro niveles de aislamiento diferentes tienen los siguientes significados:

SERIALIZABLE

Si el nivel de aislamiento es serializado, las transacciones actuales se ejecutan secuencialmente entre usuarios, uno tras otro, y este nivel de aislamiento proporciona el máximo aislamiento entre transacciones.

LECTURA REPETIBLE

En lectura repetible en este nivel de aislamiento, una transacción no se ve como una secuencia. Sin embargo, los cambios de la transacción que se está ejecutando actualmente no se pueden ver externamente, es decir, si el usuario ejecuta la misma instrucción SELECT varias veces en otra transacción, el resultado siempre es el mismo. (Porque los cambios de datos producidos por la transacción en ejecución no se pueden ver externamente).

LEER COMPROMETIDO

El nivel de aislamiento LECTURA COMPROMETIDA es menos seguro que el nivel de aislamiento LECTURA REPETIBLE. Las transacciones en el nivel de LECTURA COMPROMETIDA pueden ver modificaciones de datos por parte de otras transacciones. Es decir, durante el procesamiento de transacciones, varias declaraciones SELECT de la misma transacción pueden arrojar resultados diferentes si otras transacciones han modificado la tabla correspondiente.

LEER SIN COMPROMISO

READ UNCOMMITTED proporciona un aislamiento mínimo entre transacciones. Además de generar fácilmente operaciones de lectura fantasma y operaciones de lectura no repetibles, las transacciones en este nivel de aislamiento pueden leer datos que otras transacciones aún no han confirmado. Los cambios confirmados los deshace la transacción principal, lo que da como resultado una gran cantidad de cambios de datos.

En las bases de datos MySQL, el nivel de aislamiento de transacciones predeterminado es LECTURA REPETIBLE

1.2 Práctica SQL

A continuación, la teoría anterior se verifica al lector a través de unos simples mensajes SQL.

1.2.1 Ver el nivel de aislamiento

El nivel de aislamiento global predeterminado de la instancia de la base de datos y el nivel de aislamiento de la sesión actual se pueden ver a través del siguiente SQL:

Antes de MySQL8, use el siguiente comando para ver el nivel de aislamiento de MySQL:

SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
复制代码

El resultado de la consulta se muestra en la figura:

Como puede ver, el nivel de aislamiento predeterminado es REPEATABLE-READ, tanto el nivel de aislamiento global como el nivel de aislamiento de la sesión actual.

A partir de MySQL8, verifique el nivel de aislamiento predeterminado de MySQL con el siguiente comando :

SELECT @@GLOBAL.transaction_isolation, @@transaction_isolation;
复制代码

Es solo que la palabra clave ha cambiado, todo lo demás es igual.

El nivel de aislamiento se puede modificar con los siguientes comandos (se recomienda que los desarrolladores modifiquen el nivel de aislamiento de la sesión actual al modificar, sin modificar el nivel de aislamiento global):

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
复制代码

El SQL anterior significa establecer el nivel de aislamiento de la base de datos de la sesión actual en READ UNCOMMITTED Después de que la configuración sea exitosa, consulte el nivel de aislamiento nuevamente y descubra que el nivel de aislamiento de la sesión actual ha cambiado, como se muestra en la Figura 1-2:

Tenga en cuenta que si solo se modifica el nivel de aislamiento de la sesión actual, después de cambiar una sesión, el nivel de aislamiento se restaurará al nivel de aislamiento predeterminado, por lo que cuando hagamos pruebas, podremos modificar el nivel de aislamiento de la sesión actual.

1.2.2 LECTURA SIN COMPROMISO

1.2.2.1 Preparar datos de prueba

READ UNCOMMITTED es el nivel de aislamiento más bajo. Las lecturas sucias, las lecturas no repetibles y las lecturas fantasma existen en este nivel de aislamiento , así que veamos primero este nivel de aislamiento, para que pueda comprender cuáles son estos tres problemas.

Se presentan por separado a continuación.

Primero cree una tabla simple, preestablezca dos datos, de la siguiente manera:

Los datos en la superficie son muy simples. Hay dos usuarios, javaboy e itboyhub, y cada una de sus cuentas tiene 1000 RMB. Ahora simule una operación de transferencia entre estos dos usuarios.

Tenga en cuenta que si el lector usa Navicat para decir la verdad, diferentes ventanas de consulta corresponden a diferentes sesiones. Si el lector usa SQLyog, diferentes ventanas de consulta corresponden a la misma sesión, por lo que si usa SQLyog, debe abrir una nueva conexión. , realizar la operación de consulta en la nueva conexión.

1.2.2.2 Lecturas sucias

Cuando una transacción lee datos que no han sido confirmados por otra transacción, se denomina lectura sucia. Las operaciones específicas son las siguientes:

Primero abra dos ventanas de operaciones SQL, asumiendo A y B respectivamente, ingrese el siguiente SQL en la ventana A (no ejecute después de completar la entrada):

START TRANSACTION;
UPDATE account set balance=balance+100 where name='javaboy';
UPDATE account set balance=balance-100 where name='itboyhub';
COMMIT;
复制代码

Ejecute el siguiente SQL en la ventana B y modifique el nivel de aislamiento de transacción predeterminado a LECTURA SIN COMPROMISO, de la siguiente manera:

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
复制代码

Luego, ingrese el siguiente SQL en la ventana B. Después de completar la entrada, primero ejecute la primera línea para abrir la transacción (tenga en cuenta que solo se necesita ejecutar una línea):

START TRANSACTION;
SELECT * from account;
COMMIT;
复制代码

A continuación, ejecute los dos primeros SQL en la ventana A, es decir, abra la transacción y agregue 100 yuanes a la cuenta javaboy.
Ingrese a la ventana B y ejecute la segunda consulta SQL (SELECT * from user;) en la ventana B. Los resultados son los siguientes:

Se puede ver que aunque la transacción en la ventana A no se haya enviado, los cambios relevantes de los datos se pueden consultar en la ventana B.

Este es el problema de lectura sucia .

1.2.2.3 Lectura no repetible

Lectura no repetible significa que una transacción lee el mismo registro sucesivamente, pero los datos leídos dos veces son diferentes, lo que se denomina lectura no repetible. Los pasos específicos de la operación son los siguientes (antes de la operación, restaurar el dinero en ambas cuentas a 1000):

Primero abra dos ventanas de consulta A y B, y establezca el nivel de aislamiento de transacciones de la base de datos de B en LECTURA NO CONFIRMADA. Para SQL específico, consulte lo anterior y no entrará en detalles aquí.
Ingrese el siguiente SQL en la ventana B y luego ejecute solo los dos primeros SQL para abrir la transacción y consultar la cuenta de javaboy:

START TRANSACTION;
SELECT * from account where name='javaboy';
COMMIT;
复制代码

Los dos primeros resultados de la ejecución de SQL son los siguientes:

Ejecute el siguiente SQL en la ventana A para agregar 100 yuanes a la cuenta de javaboy, de la siguiente manera:

START TRANSACTION;
UPDATE account set balance=balance+100 where name='javaboy';
COMMIT;
复制代码

4. Regrese nuevamente a la ventana B y ejecute el segundo SQL de la ventana B para verificar la cuenta de javaboy.Los resultados son los siguientes:

La cuenta de javaboy ha cambiado, es decir, la cuenta de javaboy se verifica dos veces antes y después, y los resultados son inconsistentes, lo que es una lectura no repetible .

La diferencia con la lectura sucia es que la lectura sucia ve datos que no han sido confirmados por otras transacciones, mientras que la lectura no repetible ve datos que han sido confirmados por otras transacciones (dado que el SQL actual también está en una transacción, es posible que no desea ver otras transacciones (datos ya enviados).

1.2.2.4 Lectura fantasma

La lectura fantasmal es muy similar a la lectura no repetible, y ver nombres son alucinaciones.

Doy un ejemplo sencillo.

Introduzca el siguiente SQL en la ventana A:

START TRANSACTION;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;
复制代码

Luego ingrese el siguiente SQL en la ventana B:

START TRANSACTION;
SELECT * from account;
delete from account where name='zhangsan';
COMMIT;
复制代码

Realizamos los siguientes pasos:

Primero ejecute las dos primeras líneas de la ventana B, abra una transacción y consulte los datos en la base de datos al mismo tiempo. En este momento, los únicos datos consultados son javaboy e itboyhub.
Ejecute las dos primeras líneas de la ventana A, agregue un usuario llamado zhangsan a la base de datos, tenga cuidado de no cometer la transacción.
Ejecute la segunda línea de la ventana B. Debido al problema de lectura sucia, se puede consultar al usuario zhangsan en este momento.
Ejecute la tercera línea de la ventana B para eliminar el registro cuyo nombre es zhangsan. En este momento, habrá un problema con la eliminación. Aunque se puede consultar zhangsan en la ventana B, este registro no se ha enviado, porque se lee debido a lectura sucia. Está ahí, por lo que no se puede eliminar. En este momento, ocurrieron alucinaciones y claramente había un zhangsan, pero no se pudo eliminar.

Esta es una lectura fantasma .

Después de leer los casos anteriores, debe comprender el significado de lectura sucia , lectura no repetible y lectura fantasma .

1.2.3 LECTURA COMPROMETIDA

En comparación con READ UNCOMMITTED, READ COMMITTED resuelve principalmente el problema de las lecturas sucias, pero no para las lecturas no repetibles y las lecturas fantasma.

Después de cambiar el nivel de aislamiento de la transacción a LECTURA COMPROMETIDA, repita la prueba anterior en el caso de lectura sucia y descubra que no hay ningún problema de lectura sucia; repita la prueba anterior en el caso de lectura no repetible y descubra que el problema de lectura repetible todavía existe.

El caso anterior no se aplica a la prueba de lectura fantasma, cambiemos un caso de prueba de lectura fantasma.

O dos ventanas A y B, cambie el nivel de aislamiento de la ventana B a LECTURA COMPROMETIDA,

Luego ingrese el siguiente SQL de prueba en la ventana A:

START TRANSACTION;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;
复制代码

Ingrese el siguiente SQL de prueba en la ventana B:

START TRANSACTION;
SELECT * from account;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;
复制代码

El método de prueba es el siguiente:

Primero, ejecute las dos primeras líneas de SQL en la ventana B, abra la transacción y consulte los datos. En este momento, solo se encuentran dos usuarios, javaboy e itboyhub.
Ejecute las dos primeras líneas de SQL en la ventana A, inserte un registro, pero no confirme la transacción.
Ejecute la segunda línea de SQL en la ventana B. Dado que no hay ningún problema de lectura sucia, los datos agregados en la ventana A no se pueden encontrar en este momento.
Ejecute la tercera línea de SQL en la ventana B. Dado que el campo de nombre es único, no se puede insertar aquí. En este punto, ocurre la alucinación. Obviamente, no hay un usuario de zhangsan, pero no se puede insertar zhangsan.

1.2.4 LECTURA REPETIBLE

En comparación con READ COMMITTED, REPEATABLE READ resuelve aún más el problema de las lecturas no repetibles, pero las lecturas fantasma no.

La prueba sobre la lectura fantasma en REPEATABLE READ es básicamente la misma que la sección anterior, la diferencia es que recuerda confirmar la transacción después de ejecutar la inserción SQL en el segundo paso.

Dado que REPEATABLE READ ha resuelto la lectura no repetible, incluso si la transacción se confirma en el segundo paso, los datos confirmados no se pueden encontrar en el tercer paso y se producirá un error cuando el cuarto paso continúe con la inserción.

Tenga en cuenta que la LECTURA REPETIBLE también es el nivel de aislamiento de transacciones de la base de datos predeterminado para el motor InnoDB.

1.2.5 SERIALIZABLE

SERIALIZABLE proporciona el máximo aislamiento entre transacciones.En este nivel de aislamiento, las transacciones se ejecutan secuencialmente una tras otra, sin los problemas de lecturas sucias, lecturas no repetibles y lecturas fantasma, que es lo más seguro.

Si el nivel de aislamiento de la transacción actual se establece en SERIALIZABLE, cuando se abran otras transacciones en este momento, se bloqueará y otras transacciones deberán esperar hasta que la transacción actual se confirme antes de que otras transacciones puedan abrirse con éxito, por lo que los problemas anteriores de sucio lecturas, lecturas no repetibles y lecturas fantasma no están aquí.

1.3 Resumen

En general, la correspondencia entre los niveles de aislamiento y las lecturas sucias, las lecturas no repetibles y las lecturas fantasma es la siguiente:

nivel de aislamiento	lectura sucia	lectura no repetible	lectura fantasma
LEER SIN COMPROMISO	permitir	permitir	permitir
LEER COMPROMETIDO	No permitido	permitir	permitir
LECTURA REPETIBLE	No permitido	No permitido	permitir
SERIALIZABLE	No permitido	No permitido	No permitido

La relación de rendimiento se muestra en la figura:

Song Ge también grabó un video de nivel de aislamiento no hace mucho, puede consultar lo siguiente:

www.bilibili.com/video/BV14L…

2. Lectura instantánea y lectura actual

A continuación, debemos resolver un problema: lectura instantánea y lectura actual.

2.1 Lectura instantánea

SnapShot Read es una lectura coherente y desbloqueada, que es una de las principales razones de la alta concurrencia del motor de almacenamiento InnoDB.

Bajo el nivel de aislamiento de lectura repetible, cuando se inicia la transacción, se tomará una foto (instantánea) de la biblioteca actual. Los datos leídos por la lectura instantánea son los datos cuando se tomó la foto o los datos insertados/modificados por la transacción actual en sí misma.

Las consultas desbloqueadas que usamos todos los días, incluidas todas las consultas involucradas en la primera sección de este artículo, son lecturas instantáneas, que no demostraré.

2.2 Lectura actual

Correspondiente a la lectura instantánea es la lectura actual. La lectura actual es para leer los datos más recientes, no los datos de la versión histórica. En otras palabras, bajo el nivel de aislamiento de lectura repetible, si se usa la lectura actual, también puede leer que se han cometido otras transacciones Los datos.

Song Ge da un ejemplo:

La transacción de MySQL inicia dos sesiones A y B.

Primero inicie una transacción en la sesión A y consulte el registro con id 1:

A continuación, modificamos los datos con el id de 1 en la sesión B, de la siguiente manera:

Tenga en cuenta que la sesión B no abre la transacción ni abre la transacción de confirmación oportuna; de lo contrario, la instrucción de actualización ocupa un bloqueo exclusivo, lo que provocará el bloqueo cuando el bloqueo se utilice en la sesión A durante un tiempo.

A continuación, vuelva a la sesión A para continuar con la consulta, de la siguiente manera:

Se puede ver que la primera consulta en la sesión A es lectura instantánea, que lee el estado de los datos cuando se abre la transacción actual, y las dos últimas consultas son lecturas actuales, que leen los datos más recientes (después de la modificación en la sesión B Los datos) .

3. deshacer registro

Echemos un vistazo al registro de deshacer nuevamente, que también nos ayuda a comprender el MVCC que sigue, aquí lo presentamos brevemente.

Sabemos que la transacción de la base de datos tiene la capacidad de retroceder. Dado que se puede revertir, los datos antiguos deben registrarse antes de cambiar los datos, como base para la reversión futura, entonces este registro es el registro de deshacer.

Cuando queremos agregar un registro, registre la identificación de datos agregados en el registro de deshacer y elimine los datos en consecuencia cuando retroceda en el futuro; cuando desee eliminar o modificar datos, registre los datos originales en el registro de deshacer y restaure los datos en consecuencia en el futuro. Dado que las operaciones de consulta no implican operaciones de reversión, no es necesario registrarlas en el registro de deshacer.

4. Formato de línea

A continuación, echemos un vistazo al formato de línea, que también nos ayuda a entender MVCC.

El formato de fila es el formato en el que InnoDB guarda los datos de cada fila cuando guarda los datos de cada fila.

Hay varios formatos de fila en la base de datos, como COMPACTO, REDUNDANTE, DINÁMICO, COMPRIMIDO, etc. Sin embargo, sin importar qué formato de fila sea, las siguientes columnas de datos ocultos no se pueden evitar:

La columna 1, la columna 2, la columna 3 en la figura anterior hasta la columna N son las columnas de la tabla en nuestra base de datos, que almacenan nuestros datos normales. Además de estas columnas que guardan datos, hay tres columnas adicionales de datos agregado, estas son también las tres columnas de DB_ROW_ID, DB_TRX_ID, DB_ROLL_PTR en las que debemos centrarnos aquí:

DB_ROW_ID: esta columna ocupa 6 bytes y es un ID de fila que se utiliza para identificar de forma única una fila de datos. Si el usuario no establece la clave principal al crear la tabla, el sistema creará un índice de clave principal basado en esta columna.
DB_TRX_ID: Esta columna ocupa 6 bytes y es un ID de transacción. En el motor de almacenamiento de InnoDB, cuando queramos abrir una transacción, solicitaremos una identificación de transacción al sistema de transacciones de InnoDB. Esta identificación de transacción es un número estrictamente creciente y único . La fila de datos actual se modifica por qué transacción, será be Registre la identificación de la transacción correspondiente en la fila actual.
DB_ROLL_PTR: esta columna ocupa 7 bytes y es un puntero de reversión.Este puntero de reversión apunta a la dirección de un registro de registro de deshacer, a través del cual se puede restaurar el registro a la versión anterior.

Muy bien, esto es un poco sobre el formato de la fila de datos.

5. MVCC

Con el conocimiento preparatorio de la sección anterior, echemos un vistazo formal a MVCC.

MVCC, el nombre completo en inglés es Control de concurrencia de múltiples versiones, traducido al chino como Control de concurrencia de múltiples versiones.

La idea central de MVCC es guardar la versión histórica de la fila de datos y realizar el control de concurrencia de la base de datos administrando múltiples versiones de la fila de datos.

En pocas palabras, cuando los registros que solemos ver se almacenan en la base de datos, puede que no haya un solo registro, sino múltiples versiones históricas.

Como se muestra abajo:

Esta imagen se entiende bien, y creo que el MVCC de todos no se entiende mucho.

A continuación, les contaré sobre esta imagen en combinación con diferentes niveles de aislamiento.

5.1 LECTURA REPETIBLE

Primero, cuando operamos una fila de datos a través de INSERT\DELETE\UPDATE, se generará una identificación de transacción, y esta identificación de transacción también se almacenará en el registro de fila (DB_TRX_ID), es decir, qué transacción modifica la fila de datos actual. Posteriormente, se graba.

Las operaciones INSERT\DELETE\UPDATE generarán el registro de registro de deshacer correspondiente. Cada fila de registros tiene un DB_ROLL_PTR que apunta al registro de registro de deshacer. Para cada fila de registros, al ejecutar el registro de registro de deshacer, puede restaurar el registro anterior, anterior registro, registro anterior Pre-registro...

Cuando abrimos una transacción, primero solicitaremos una identificación de transacción al sistema de transacciones de InnoDB. Esta identificación es un número estrictamente creciente. En el momento en que se abre la transacción actual, el sistema creará una matriz y la matriz guardará todo ID de transacción activa actual, la llamada transacción activa se refiere a la transacción que se ha abierto pero que aún no se ha comprometido.

El valor mínimo en esta matriz es fácil de entender. Algunos amigos pueden pensar erróneamente que el valor máximo en la matriz es la identificación de la transacción actual. De hecho, esto no es necesariamente y puede ser mayor. Debido a que lleva tiempo desde la aplicación hasta trx_id y la creación de la matriz, otras sesiones también pueden solicitar trx_id durante este período.

Cuando la transacción actual quiere ver una fila de datos, primero verificará el DB_TRX_ID de la fila de datos:

Si este valor es igual al id de la transacción actual, significa que la transacción actual lo modificó y los datos son visibles.
Si este valor es menor que el valor mínimo en la matriz, significa que cuando comenzamos la transacción actual, la transacción involucrada en la modificación de datos de esta fila se ha confirmado y la fila de datos actual es visible.
Si este valor es mayor que el valor máximo en la matriz, significa que esta fila de datos está después de que abrimos la transacción, pero antes de confirmar, otra sesión también abre la transacción y modifica esta fila de datos, entonces esta fila de datos es Invisible.
Si el tamaño de este valor está entre los valores máximo y mínimo en la matriz (rango cerrado), y el valor no está en la matriz, significa que estos también son los datos modificados por una transacción confirmada, que es visible.
Si el tamaño de este valor está entre los valores máximo y mínimo en la matriz (rango cerrado), y el valor está en la matriz (no es igual a la identificación de la transacción actual), significa que estos son los datos modificados por un transacción no confirmada y no es visible.

Las tres primeras situaciones deben ser bien entendidas, principalmente las dos últimas Song Ge da un ejemplo simple.

Por ejemplo, tenemos cuatro sesiones A, B, C y D. Primero, A, B y C inician una transacción, respectivamente. Los ID de transacción son 3, 4 y 5. Luego, la sesión C confirma la transacción, pero A y B no. A continuación, la sesión D también inicia una transacción, el ID de transacción es 6, luego, cuando la sesión D inicia la transacción, el valor en la matriz es [3,4,6]. Ahora supongamos que hay una fila de datos cuyo DB_TRX_ID es 5 (el cuarto caso), entonces la fila de datos es visible (porque se ha confirmado cuando se abre la transacción actual); si hay una fila de datos cuyo DB_TRX_ID es 4 , entonces la fila no es visible (porque no está comprometida).

Otro punto a tener en cuenta es que si las operaciones de actualización de datos están involucradas en la transacción actual, las operaciones de actualización se actualizan sobre la base de la lectura actual, no sobre la base de la lectura instantánea. Si es lo último, puede haber pérdida de datos. resultado.

Permítanme dar un ejemplo, asumiendo la siguiente tabla:

Ahora hay dos sesiones A y B, primero inicie una transacción en A:

Luego realice una operación de modificación en la sesión B (sin abrir explícitamente la transacción, la transacción se abrirá dentro del SQL de actualización y la transacción se confirmará automáticamente después de que se complete la actualización):

Luego, regrese a la sesión A, consulte el registro y descubra que el valor no ha cambiado, como se esperaba (actualmente el nivel de aislamiento es de lectura repetible), luego realice una operación de modificación en A y luego consulte después de que se complete la modificación, como mostrado a continuación:

Se puede ver que la actualización en realidad se actualiza sobre la base de 100, lo cual es fácil de entender.Si se actualiza sobre la base de 99, se perderá la actualización de 100, lo que obviamente es incorrecto.

De hecho, la actualización en MySQL es leer primero y luego actualizar, al leer, el valor predeterminado es la lectura actual, es decir, estará bloqueada. Entonces, en el caso anterior, si la transacción se abre explícitamente en la sesión B y no hay ningún compromiso, la declaración de actualización en la sesión A se bloqueará.

Esto es MVCC y hay varias versiones de un solo registro. Realiza el control de concurrencia de lectura y escritura, y las lecturas y escrituras no se bloquean entre sí; al mismo tiempo, se adopta el bloqueo optimista en MVCC, la lectura de datos no está bloqueada y la escritura de datos solo bloquea filas, lo que reduce la probabilidad de interbloqueo; y la lectura de instantáneas también se puede realizar en consecuencia.

5.2 LECTURA COMPROMETIDA

READ COMMITTED es similar a REPEATABLE READ, la principal diferencia es que este último crea una vista consistente (creando una matriz para enumerar las identificaciones de transacciones activas) al comienzo de cada transacción, mientras que el primero vuelve a calcular una nueva vista antes de que se ejecute cada declaración.

Por lo tanto, el nivel de aislamiento de LECTURA COMPROMETIDA verá los datos que otras sesiones han confirmado (incluso si la otra sesión se abre más tarde que la sesión actual).

6. Resumen

MVCC logra la simultaneidad de lectura y escritura hasta cierto punto, pero solo es válido en los dos niveles de aislamiento de LECTURA COMPROMETIDA y LECTURA REPETIBLE.

Mientras que READ UNCOMMITTED siempre lee la fila de datos más reciente, SERIALIZABLE bloquea todas las filas de lectura, las cuales son incompatibles con MVCC.

Vale, no sé si lo entendéis. Si tenéis alguna pregunta, dejad un mensaje para debatirlo.

Autor: A Little Rain in Jiangnan
Enlace: https://juejin.cn/post/7044043884694863902
Fuente: Rare Earth Nuggets
Los derechos de autor pertenecen al autor. Para reimpresiones comerciales, comuníquese con el autor para obtener autorización, y para reimpresiones no comerciales, indique la fuente.

Es 2022, es demasiado frustrante si no entiendes MVCC