'Waiting for table metadata lock' diagnostizieren und den eigentlichen Blocker finden

Befehl

-- 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;

Was es tut

Zeigt, auf den Metadata Lock welcher Session eine DDL wie ALTER / TRUNCATE / RENAME wartet, und welche Abfragen sich hinter der DDL anstauen. Der Blocker ist meist eine Session in Sleep, die die Tabelle gelesen und ihre Transaktion nie beendet hat.

Wann einsetzen

Wenn sich nach dem Start eines ALTER alle Abfragen auf dieser Tabelle in 'Waiting for table metadata lock' stauen.

Vorsicht

Eine wartende DDL blockiert auch die danach eintreffenden SELECTs; entscheide im Incident schnell: die blockierende Session per KILL beenden oder das ALTER abbrechen (KILL QUERY). PROCESSLIST_INFO des Blockers kann NULL sein (inaktiv); seine letzte Anweisung siehst du in performance_schema.events_statements_history oder sys.session.last_statement. Vorbeugung: DDL nach SET SESSION lock_wait_timeout = 5 ausführen, damit das ALTER schnell aufgibt, und lange offene Transaktionen in der Anwendung vermeiden.