MySQL出现Waiting for table metadata lock说明DDL操作被挂起，因需等待X锁而阻塞后续所有DML，形成连锁阻塞；真正持锁的是未提交事务中的Sleep线程，须通过performance_schema.metadata_locks与INNODB_TRX交叉定位并KILL thread释放。
Waiting for table metadata lock 不是系统“卡死”，而是某个 DDL 操作（比如 ALTER TABLE、TRUNCATE TABLE）被挂起，它在等一个元数据锁（MDL）释放。真正让系统雪崩的，是这个等待本身会阻塞后续所有对该表的 DML（SELECT/INSERT/UPDATE），形成连锁阻塞。
为什么一个 Sleep 线程能卡住整个表？
MySQL 的 MDL 锁由事务生命周期控制，不是由连接状态决定的：
- 一个显式事务（BEGIN 后执行了 SELECT 或 SELECT ... FOR UPDATE）只要没 COMMIT 或 ROLLBACK，就一直持有 SHARED_READ 或 SHARED_WRITE MDL 锁
- 这个线程在 PROCESSLIST 里显示为 Command = 'Sleep'、State = ''、Time 却持续增长，但它底层的 trx_state = 'RUNNING'
- DDL 需要 X（排他）MDL 锁，必须等所有 S 锁释放，而这个“安静”的事务就是那个不放锁的源头
查不到阻塞源？别只看 SHOW PROCESSLIST
SHOW PROCESSLIST 根本不显示 MDL 持有关系，因为它是服务层锁，不走 InnoDB 引擎层。
必须用以下方式交叉验证：
- 先查持锁者：
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS, PROCESSLIST_ID FROM performance_schema.metadata_locks WHERE LOCK_STATUS = 'GRANTED' AND OBJECT_NAME = 'your_table'; - 再查对应事务：
SELECT trx_id, trx_started, trx_state, trx_mysql_thread_id FROM information_schema.INNODB_TRX WHERE trx_mysql_thread_id = ?; - 最后反查它最后执行的语句：
SELECT SQL_TEXT FROM performance_schema.events_statements_current WHERE THREAD_ID = ?;
如果 SQL_TEXT 为空，且 trx_state = 'RUNNING'，基本可断定是悬挂事务。
为什么 kill QUERY 没用，kill thread 才可能生效？
KILL QUERY 只中断当前正在执行的语句，对已经 Sleep 但事务未结束的连接无效。KILL [thread_id] 才会强制回滚事务并释放 MDL 锁，但要注意：
- 别一上来就 KILL——先用
SHOW ENGINE INNODB STATUS\G搜索对应trx_id，确认mysql tables in use和locked tables都为 0，说明事务确实空转中 - 如果该线程正处在 binlog 写入或两阶段提交中间态，KILL 可能导致主从不一致
- 应用层用了连接池时，KILL 掉的是复用连接，但业务代码可能仍认为事务还在继续
sys.schema_table_lock_waits 是最快定位路径，但有前提
这个视图能直接输出 blocking_pid 和 waiting_pid，但依赖两个开关：
-
performance_schema必须启用：SELECT @@performance_schema;返回 1 -
wait/lock/metadata/sql/mdl采集器必须开启：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/metadata/sql/mdl';
一旦启用，SELECT * FROM sys.schema_table_lock_waits\G 就能秒级看到谁堵了谁。但如果返回空，不代表没锁——很可能是隐式事务或连接已断开但事务残留，这时必须退回 INNODB_TRX + PROCESSLIST 联查。
真正容易被忽略的点在于：MDL 阻塞不是“锁表”，而是“锁定义”。一个没提交的 SELECT 就足以让 ALTER TABLE 等上几小时，而你在 PROCESSLIST 里只看到一堆安静的 Sleep 线程。定位它，靠的不是状态，而是时间戳和事务状态的错位。
