I. Introducción
En una reunión de revisión reciente, un colega mencionó que una condición inexistente para la actualización causó bloqueos de tablas, y luego se produjo una gran cantidad de fallas en las transacciones y tiempos de espera de lectura y escritura. En este momento, el blogger era muy extraño, porque aunque muchos Los blogs en Internet escribieron sobre los bloqueos de tablas de Innodb, los bloqueos de filas y las actualizaciones de bloqueos, pero en realidad todos estos son puntos de vista erróneos.
2. Análisis
En primer lugar, el entorno del blogger es Mysql5.7 y el nivel de aislamiento es RC.
¿Por qué los blogueros dicen que estas son opiniones equivocadas? Porque en "High Performance Mysql" y "Innodb Storage Engine", se establece muy claramente:
1. Innodb no tiene actualizaciones de bloqueo, por lo que no hay actualización de bloqueos de fila a bloqueos de tabla debido a la gran cantidad de datos bloqueados o varias tablas.
2. Cuando para actualizar una condición donde no existe, Innodb agrega un bloqueo de nivel de registro
Esto puede ser verificado por
| donde no existe | establecer autocompromiso = 0;
seleccione * de t_aac_battery_compensate donde gmt_create en ('2020-05-21 07:02:37') para actualizar; |
|---|---|
| donde existe | comenzar; seleccione * de t_aac_*** donde gmt_create en ('2020-05-21 07:32:37') para actualizar; |
Luego ejecute
select * from information_schema.INNODB_LOCKS il
puede ver la cerradura
Se puede ver que ambas transacciones agregan bloqueos a nivel de fila.
Algunos estudiantes pueden tener dudas sobre la cantidad de filas y datos bloqueados. El blogger aquí descubrió que las estadísticas de estos dos valores son inexactas, incluido el hecho de que el autor de "Innodb Storage Engine" declaró claramente que lock_data es inexacto.
Algunos estudiantes también se preguntaron por qué agregó bloqueos de fila para bloquear otras lecturas y escrituras Aquí, innodb agregó bloqueos de fila y finalmente los liberó juntos, aunque no sé por qué está diseñado así.
3. Si Innodb no puede encontrar un registro en el índice, buscará los datos de la fila y bloqueará la clave principal en lugar de bloquear la tabla.
Entonces, algunos blogs dicen que innodb bloqueará toda la tabla si el bloqueo no se puede agregar al índice, lo cual es un error de interpretación.
Es solo que en algunos casos, buscó datos de fila y bloqueó demasiadas claves primarias. También dije que innodb más los bloqueos de fila se liberan al final, por lo que se bloquean otras lecturas y escrituras.
4. Innodb bloquea de arriba a abajo. El bloqueo automático solo incluye bloqueos de intención de nivel de tabla y bloqueos de nivel de fila. Los bloqueos de intención de nivel de tabla solo bloquean exploraciones de tabla completa.
5. Situación de bloqueo del nivel de RR
Todo lo anterior se basa en la configuración del entorno en línea del blogger. Si es el nivel de aislamiento RR, habrá GapLock y bloqueos de fila para el bloqueo del algoritmo Next_keyLock. De hecho, es simplemente para bloquear la especie de árbol B+ actual entre el índice actual y el índice anterior (o la línea actual a la línea anterior) para evitar que se inserten datos durante este proceso, es decir, para evitar la lectura fantasma.
Pero esta situación no es absoluta. Para índices únicos, InnoDB reducirá el nivel de bloqueos de nivel de fila y no bloqueará el rango.
3. Resumen
A través del análisis anterior, se concluye que:
1. InnoDB en el nivel de RC es todos los bloqueos de nivel de fila, y los bloqueos de intención de nivel de tabla solo bloquearán los escaneos de tabla completos
2. No hay actualización de bloqueo en innodb
3. Si innodb no puede agregar un índice, buscará filas y bloqueará la clave principal
4. Cuando para actualizar una condición donde no existe, Innodb agrega un bloqueo de nivel de registro