Cómo ver y resolver bloqueos en MySQL
Cuando las consultas se quedan colgadas, casi siempre es porque una transacción espera un lock que otra retiene. MySQL 8.0 permite ver quién bloquea a quién sin adivinar, usando processlist, el estado de InnoDB y las vistas de data locks.
- 1
Mira qué consultas están corriendo o esperando
La columna State y un Time alto delatan las consultas atoradas. Es tu primer vistazo al problema.
SELECT id, user, host, db, command, time, state, LEFT(info, 80) AS consulta FROM information_schema.processlist WHERE command <> 'Sleep' ORDER BY time DESC; - 2
Identifica quién bloquea a quién
La vista data_lock_waits de performance_schema muestra la transacción que espera y la que la bloquea, sin interpretar texto crudo.
SELECT waiting_pid, blocking_pid, waiting_query, blocking_query FROM sys.innodb_lock_waits; - 3
Revisa el último deadlock detectado
SHOW ENGINE INNODB STATUS incluye una sección LATEST DETECTED DEADLOCK con las dos transacciones y las llaves en conflicto.
SHOW ENGINE INNODB STATUS\G - 4
Corta la transacción bloqueadora solo si es necesario
KILL termina la conexión y provoca rollback de su transacción. Es una acción destructiva: se pierde el trabajo no confirmado de esa sesión. Úsalo como último recurso y sobre la conexión correcta.
KILL 1234; -- 1234 es el id de la conexión bloqueadora
// el error común
Matar la conexión equivocada puede interrumpir un proceso legítimo y disparar un rollback largo que empeora todo. Confirma el id contra processlist antes de ejecutar KILL, y ataca la causa (transacciones largas, falta de índices) no solo el síntoma.
// cuándo conviene un experto
Los deadlocks recurrentes suelen ser un problema de diseño de transacciones o de índices, no mala suerte. En dba.mx analizamos el patrón de bloqueos y ajustamos el modelo de acceso, con techo cerrado.
Agenda un Escaneo — desde USD $550Esta guía es orientativa y usa comandos de referencia. En producción, adapta a tu versión y prueba en un ambiente seguro primero.