Diagnosticar 'Waiting for table metadata lock' y encontrar el bloqueador real
MySQLRendimientoComando
-- Waiter -> blocker pairs; filter out the ALTER's own SHARED_UPGRADABLE entry
SELECT object_schema, object_name, waiting_pid, LEFT(waiting_query, 60) AS waiting_query,
waiting_lock_type, blocking_pid, blocking_lock_type, sql_kill_blocking_connection
FROM sys.schema_table_lock_waits
WHERE blocking_lock_type <> 'SHARED_UPGRADABLE';
-- All MDLs on the table, owner age and open transaction
SELECT ml.OBJECT_SCHEMA, ml.OBJECT_NAME, ml.LOCK_TYPE, ml.LOCK_DURATION, ml.LOCK_STATUS,
t.PROCESSLIST_ID AS conn_id, t.PROCESSLIST_COMMAND AS command, t.PROCESSLIST_TIME AS sec,
LEFT(t.PROCESSLIST_INFO, 60) AS query, trx.trx_started
FROM performance_schema.metadata_locks ml
JOIN performance_schema.threads t ON t.THREAD_ID = ml.OWNER_THREAD_ID
LEFT JOIN information_schema.INNODB_TRX trx ON trx.trx_mysql_thread_id = t.PROCESSLIST_ID
WHERE ml.OBJECT_TYPE = 'TABLE' AND ml.OBJECT_SCHEMA NOT IN ('performance_schema', 'mysql')
ORDER BY ml.OBJECT_NAME, ml.LOCK_STATUS DESC;Qué hace
Muestra en el metadata lock de qué sesión espera un DDL como ALTER / TRUNCATE / RENAME, y las consultas encoladas detrás del DDL. El bloqueador suele ser una sesión en Sleep que leyó la tabla y nunca cerró su transacción.
Cuándo usarlo
Cuando, tras iniciar un ALTER, todas las consultas sobre esa tabla se acumulan en 'Waiting for table metadata lock'.
Precaución
Un DDL en espera también bloquea los SELECT que llegan después; decida rápido durante el incidente: KILL de la sesión bloqueadora o cancelar el ALTER (KILL QUERY). PROCESSLIST_INFO del bloqueador puede ser NULL (inactivo); use performance_schema.events_statements_history o sys.session.last_statement para ver su última sentencia. Prevención: ejecute el DDL después de SET SESSION lock_wait_timeout = 5 para que el ALTER desista rápido, y evite transacciones abiertas largas en la aplicación.
Relacionado
- Encontrar las consultas más costosas (performance_schema digest)
- Qué se está ejecutando ahora: sesiones activas, latencia, bloqueos y transacciones (sys.session)
- Analizar los deadlocks de InnoDB y registrarlos todos
- Transacciones de larga duración e history list length (retraso de purge)
- Capturar un slow log completo breve y analizarlo con pt-query-digest
- Depurar un mal plan con EXPLAIN ANALYZE y el optimizer trace