Uno, deshacer la cadena de versión de registro
Cuando ejecutamos actualizar, insertar, eliminar, se generará el registro de deshacer para evitar la reversión.
Una ejecución de SQL generará un registro de registro de deshacer:
Entre ellos, trx_id es la identificación de la transacción que ejecuta este sql, roll_pointer apunta al registro de deshacer modificado al mismo valor, porque no hay corriente, apunta a un objeto vacío.
Hay otro SQL para modificar estos datos, el ID de la transacción es 51 y el valor se cambia a B:
Modifique el mismo dato y conéctelo a través de roll_pointer para formar una cadena de versión de registro de deshacer.
Segundo, el mecanismo ReadView
Cuando se ejecuta una transacción, se genera un ReadView, que incluye:
1.m_ids: la identificación de la transacción aún no se ha enviado
2.min_trx_id: la identificación de transacción más pequeña en m_ids
3.max_trx_id: la próxima identificación de transacción generada por mysql
4.creator_trx_id: la identificación de la transacción actual, que es la identificación de la transacción que creó esta Vista de lectura
Por ejemplo, ahora hay una transacción A y una transacción B para modificar los datos, y la vista de lectura generada por la transacción A:
Tres, principio de implementación de nivel RR de MySQL
Entonces, ¿cómo implementar el mecanismo mysql MVCC basado en la cadena de versión de deshacer registro y ReadView?
Echemos un vistazo al nivel RR predeterminado de MySQL, que resuelve los problemas de lectura sucia, lectura no repetible y lectura fantasma:
Lectura sucia: la transacción B se inicia y el registro de deshacer genera un registro. En este momento, la transacción A llega a consulta. El registro de deshacer con el valor B, trx_id es 60, que es mayor que creator_trx_id: 50 de ReadView en la transacción A. Significa que se ejecutó antes de que comenzara la transacción A. Verifique que m_ids esté efectivamente en esta colección. Explique que esta transacción y la transacción A están ocurriendo al mismo tiempo y continúan bajando. El trx_id del siguiente registro es 50, es decir, se puede consultar la identificación de su transacción y el valor de retorno es A. Esto resuelve el problema de la lectura sucia.
Lectura no repetible: antes de que comience la transacción B, el valor consultado por la transacción A es A. Después del envío, el valor consultado por la transacción A sigue siendo A, lo que resuelve el problema de la lectura no repetible.
Lectura fantasma: por ejemplo, para ejecutar un sql: seleccione count (*) donde id> 10;
Cuando la transacción A comenzó a consultar, solo tres elementos cumplían las condiciones. La transacción B ahora inserta una pieza de datos con id 6. La transacción A se utiliza para consultar los datos con id> 10. Se encuentra que hay 2 condiciones de consulta compuestas, una es la original 3 y la otra es 4 después de que se envía la transacción B. La transacción A tiene un trx_id más pequeño que la transacción B, y está en m_ids, por lo que los datos originales devueltos siguen siendo 3. Esto resuelve el problema de la lectura fantasma.