Las cerraduras en MySQL no son un concepto monolítico. Este artículo desglosa sistemáticamente el sistema de cerraduras de InnoDB desde tres perspectivas, ayudándote a construir un marco de conocimiento claro para la práctica y las entrevistas.

Panorama General de las Cerraduras

Para entender las cerraduras de MySQL, puedes abordarlas desde tres dimensiones:

Dimensión	Tipo de Cerradura	Propósito Principal
Partición por Granularidad	Global, Tabla, Fila	Controlar el alcance de los datos bloqueados (InnoDB se enfoca principalmente en bloqueos de fila)
Partición por Compatibilidad	Compartida (S), Exclusiva (X)	Determinar si múltiples transacciones pueden operar sobre los mismos datos simultáneamente
Algoritmo de Cerradura	Registro, Brecha, Clave Siguiente	Determinar la posición dentro del árbol B+ donde se aplica la cerradura

Primera Capa: Granularidad de la Cerradura — ¿Dónde aplicas el bloqueo?

Nivel de Cerradura	Analogía	Escenario SQL Correspondiente	Impacto
Global	Bloquear todo el edificio, impidiendo la entrada y salida	FLUSH TABLES WITH READ LOCK (copia de seguridad completa de la base de datos)	Interrupción total del negocio, raramente utilizada manualmente
Tabla	Renovar todo un piso de un edificio	LOCK TABLES o Metadatos de Bloqueo (MDL)	Afecta a toda la tabla, baja concurrencia
Fila	Bloquear una habitación específica	UPDATE ... WHERE id = 1	La característica principal de InnoDB, máxima concurrencia

Segunda Capa: Compatibilidad de la Cerradura — Cerraduras S y X

Esta es la lógica fundamental de todas las cerraduras:

• Cerradura Compartida (S / Cerradura de Lectura): Yo puedo leer, tú también puedes leer, pero nadie puede modificar. Se activa con: SELECT ... FOR SHARE
• Cerradura Exclusiva (X / Cerradura de Escritura): Yo voy a modificar, nadie más puede tocar. Se activa con: UPDATE / DELETE / SELECT ... FOR UPDATE

Es importante notar que un SELECT normal no aplica ninguna cerradura (lectura instantánea). Solo las sentencias explícitas de bloqueo la activan.

Cerraduras de Intención: "Saludar" a Nivel de Tabla

Cuando estás a punto de aplicar una cerradura X a una fila, MySQL primero aplicará una Cerradura de Intención Exclusiva (IX) a nivel de tabla.

¿Por qué es necesaria? Imagina una tabla con 160 millones de filas. Si otra transacción quisiera aplicar un bloqueo de tabla sin cerraduras de intención, la base de datos tendría que iterar sobre 160 millones de filas para verificar si hay alguna cerradura de fila. Con las cerraduras de intención, basta con un vistazo al encabezado de la tabla. Es una estrategia de "espacio por tiempo".

Características clave: Las cerraduras de intención son compatibles entre sí, y las cerraduras de intención son compatibles con las cerraduras de fila. Solo son incompatibles con las cerraduras de nivel de tabla.

Tercera Capa: Tres Algoritmos de Bloqueo de Fila — La Esencia de InnoDB

Estas son cerraduras físicas basadas en el árbol B+, y son los puntos más frecuentes en las entrevistas.

Cerradura de Registro (Record Lock)

Bloquea con precisión una hoja específica en el árbol de índices.

-- Golpea con precisión, solo bloquea la fila con pk_id = 10
SELECT * FROM t_mqtt_log WHERE pk_id = 10 FOR UPDATE;

Cerradura de Brecha (Gap Lock)

Bloquea la "brecha" entre dos registros de índice, sin incluir los registros en sí. Su propósito es prevenir la lectura fantasmal, impidiendo que otras transacciones inserten nuevos datos en esta brecha.

Analogía: Colocar un cartel de "En Construcción" en el pasillo entre la habitación 101 y la 105. ¿Alguien quiere insertar una nueva habitación, la 102? Lo siento, el pasillo está cerrado.

Cerradura de Clave Siguiente (Next-Key Lock)

Es una combinación de Cerradura de Registro + Cerradura de Brecha. Bloquea un rango e incluye el registro en sí. Este es el algoritmo de bloqueo de fila predeterminado de InnoDB en el nivel de aislamiento REPEATABLE READ.

Relación Fundamental entre Cerraduras e Índices

Recuerda un principio: Las cerraduras en MySQL se aplican a los "índices", no a las "filas".

Incluso si no tienes una clave primaria ni un índice único al crear la tabla, InnoDB creará automáticamente una columna oculta RowID como índice clúster.

Esto significa:

• Consulta que coincide con el índice de la clave primaria → Cerradura de registro precisa
• No coincide con el índice, lo que resulta en un escaneo completo de la tabla → La cerradura se actualiza a una Cerradura de Clave Siguiente que cubre toda la tabla
• En REPEATABLE READ, las cerraduras de brecha evitan la lectura fantasmal; en READ COMMITTED, básicamente no hay cerraduras de brecha

En la Práctica: Tres Pasos para Entender las Cerraduras

No necesitas memorizar. Puedes sentirlo de manera intuitiva abriendo dos ventanas de terminal.

Paso 1: Crear una "Confrontación"

Ventana A - Iniciar transacción y aplicar bloqueo:

BEGIN;
SELECT * FROM t_mqtt_log WHERE pk_id = 10 FOR UPDATE;

Ventana B - Intentar modificar la misma fila (será bloqueada):

UPDATE t_mqtt_log SET type = 1 WHERE pk_id = 10;
-- En este punto, B se quedará colgado, esperando que A libere la cerradura.

Paso 2: Ver la "Escena del Crimen"

En una tercera ventana, ejecuta:

SELECT * FROM performance_schema.data_locks;

Verás claramente: qué hilo tiene la cerradura, a qué árbol B+ está bloqueado, si es una cerradura X o GAP, e incluso podrás ver el pk_id específico de la cerradura.

Paso 3: Analizar Deadlocks

SHOW ENGINE INNODB STATUS;

En la sección LATEST DETECTED DEADLOCK, verás el escenario completo del deadlock: quién espera a quién, y quién fue finalmente sacrificado por MySQL.

Deadlocks: Principios y Soluciones

La ocurrencia de deadlocks requiere el cumplimiento de cuatro condiciones necesarias (Condiciones de Coffman):

1. Exclusión Mutua: Un recurso solo puede ser bloqueado por una transacción a la vez.
2. Ocupar y Esperar: Una transacción ya tiene un bloqueo y solicita otro que está siendo retenido por otra transacción.
3. No Arbitrariedad: Los bloqueos retenidos por una transacción no pueden ser arrebatados por la fuerza hasta que la transacción se complete.
4. Espera Circular: A espera a B, y B espera a A, formando un ciclo.

Escenario Clásico de Deadlock

Momento	Transacción A	Transacción B
T1	UPDATE users SET name='A' WHERE id=1; (obtiene el bloqueo para ID=1)
T2		UPDATE users SET name='B' WHERE id=2; (obtiene el bloqueo para ID=2)
T3	UPDATE users SET name='A2' WHERE id=2; (bloqueada, esperando que B libere ID=2)
T4		UPDATE users SET name='B2' WHERE id=1; (¡Deadlock! B intenta obtener ID=1, pero A lo tiene)

Mecanismo de Detección de Deadlocks de InnoDB

InnoDB detecta activamente deadlocks utilizando un Grafo de Espera (Wait-for Graph). Tan pronto como detecta un ciclo, declara un deadlock.

1. Mantiene un grafo de relaciones de espera de bloqueo. Una vez que se detecta un ciclo, se determina el deadlock.
2. Selecciona la transacción con el menor costo para revertir (generalmente, la que ha actualizado menos filas, o tiene menos Undo Log).
3. La transacción revertida libera todos sus bloqueos, y la otra transacción continúa ejecutándose.
4. La aplicación recibe el error clásico: Deadlock found when trying to get lock; try restarting transaction

Estrategias de Prevención a Nivel de Código

Los deadlocks no se pueden eliminar por completo, pero las siguientes estrategias pueden reducir significativamente su probabilidad:

1. Secuancia de Acceso Fija: Todas las lógicas de negocio operan sobre los recursos en el mismo orden (primero ID=1, luego ID=2). Esto rompe la espera circular desde la raíz.
2. Desglosar Transacciones Grandes: Cuanto más tiempo se ejecuta una transacción, más tiempo retiene bloqueos, y mayor es la probabilidad de colisiones.
3. Utilizar Índices Adecuadamente: Cuando un índice no se encuentra, el bloqueo puede escalar (Cerradura de Clave Siguiente o incluso bloqueo de toda la tabla). Cuanto mayor sea el alcance del bloqueo, mayor será la probabilidad de deadlock.
4. Reducir el Nivel de Aislamiento: Si el negocio lo permite, reducir de RR a RC puede eliminar la mayoría de las cerraduras de brecha, reduciendo los deadlocks.

Preguntas Frecuentes Adicionales

Metadatos de Bloqueo (MDL) — Zona de Alto Riesgo de Accidentes en Línea

MDL no se aplica a los datos, sino a la estructura de la tabla. Un escenario catastrófico típico:

1. Una transacción A ejecuta una consulta SELECT lenta (aún no finalizada), reteniendo un bloqueo MDL de lectura.
2. Tú ejecutas ALTER TABLE para agregar un campo, solicitando un bloqueo MDL de escritura, y te bloqueas por A.
3. A partir de entonces, todas las nuevas consultas SELECT serán bloqueadas por este ALTER TABLE.
4. El pool de conexiones explota enstantáneamente, el servicio colapsa.

Conclusión: Nunca realices ALTER TABLE en tablas grandes durante las horas pico en línea, a menos que hayas evaluado explícitamente el impacto de MDL.

Cerradura Auto-Incrementada (AUTO-INC Locks)

Para escenarios de inserción de alta concurrencia (por ejemplo, t\_mqtt\_log insertando miles de veces por segundo), todas las transacciones compiten por el siguiente ID autoincremental. InnoDB coordina esto a través de la cerradura autoincremental, y el parámetro clave de ajuste es innodb_autoinc_lock_mode:

• 0 (Modo Tradicional): Bloqueo a nivel de sentencia, peor concurrencia.
• 1 (Modo Continuo): Las inserciones simples usan un bloqueo ligero, las inserciones masivas usan un bloqueo a nivel de sentencia (predeterminado en MySQL 5.x).
• 2 (Modo Intercalado): Concurrencia total, el mejor rendimiento, pero los valores autoincrementales de las inserciones masivas pueden no ser consecutivos (predeterminado en MySQL 8.0).

Cerradura Pesimista vs. Cerradura Optimista

Esta es una elección de estrategia de bloqueo a nivel de lógica de negocio:

• Cerradura Pesimista: SELECT ... FOR UPDATE. Ocupa el lugar primero y luego trabaja. Adecuado para escenarios con conflictos de escritura frecuentes.
• Cerradura Optimista: Controlada por un número de versión. UPDATE ... SET version = version + 1 WHERE id = 1 AND version = ?. No bloquea filas. Comprueba si ha sido modificado al confirmar. Adecuado para escenarios con lectura frecuente y escritura ocasional.

Resumen

Punto Clave	Puntos Esenciales
Granularidad de la Cerradura	Global > Tabla > Fila; InnoDB se enfoca en filas
Cerraduras S / X	Las cerraduras compartidas permiten lectura concurrente, las exclusivas bloquean lectura/escritura
Cerraduras de Intención	Marcadores a nivel de tabla para evitar la comprobación fila por fila al aplicar bloqueos de tabla
Cerradura de Registro	Bloquea con precisión un registro en el índice
Cerradura de Brecha	Bloquea la brecha entre registros para prevenir lecturas fantasma
Cerradura de Clave Siguiente	Cerradura de registro + Cerradura de brecha; algoritmo de bloqueo de fila predeterminado de InnoDB
Cerraduras se aplican a Índices	No encontrar índice → La cerradura escala; mayor alcance, mayor probabilidad de deadlock
Detección de Deadlocks	Detección de ciclos mediante Grafos de Espera; revierte la transacción de menor costo
MDL	Bloqueo de estructura de tabla; ALTER TABLE durante horas pico puede causar colapso del servicio