真正要KILL的是blocking_pid对应的持锁连接，而非显示“Waiting for table metadata lock”的等待线程；优先用KILL QUERY，通过sys.schema_table_lock_waits可直接获取阻塞链，blocking_pid为NULL时可能为隐式事务悬挂持锁。
查 sys.schema_table_lock_waits 快速定位阻塞源头
看到 Waiting for table metadata lock，别急着 KILL 那个“等待中”的线程——它只是受害者。真正要找的是 blocking_pid，也就是持锁不放的那个连接 ID。
执行这句就能直接看到谁堵了谁：
SELECT * FROM sys.schema_table_lock_waits\G
注意几个关键点：
- 如果返回为空，先确认
performance_schema已启用：SELECT @@performance_schema;结果必须是1 - 再检查采集器是否打开：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/metadata/sql/mdl'; -
blocking_pid为NULL不代表没锁，很可能是隐式事务（比如BEGIN后只跑了一条SELECT就断开）在持锁 -
sql_text字段能直接看到持锁者最后执行的语句，比如一个没提交的SELECT或空闲BEGIN
联合 INNODB_TRX 和 PROCESSLIST 找“Sleep 却 RUNNING”的悬挂事务
大量 MDL 阻塞源根本不在活跃执行状态里，而是那种 COMMAND = 'Sleep'、STATE 为空、但 trx_state = 'RUNNING' 的连接。它从 BEGIN 开始就一直占着 MDL_SHARED_READ 锁。
单查 INNODB_TRX 会漏掉已断连但事务未清理的连接，必须用 JOIN：
SELECT t.trx_id, t.trx_started, t.trx_state, t.trx_isolation_level, p.ID, p.USER, p.HOST, p.DB, p.COMMAND, p.TIME, p.STATE, p.INFO FROM information_schema.INNODB_TRX t JOIN information_schema.PROCESSLIST p ON t.trx_mysql_thread_id = p.ID WHERE p.COMMAND = 'Sleep' AND t.trx_state = 'RUNNING' ORDER BY t.trx_started;
重点关注：
-
TIME > 300且INFO为空 → 极大概率是应用异常中断或忘记COMMIT -
trx_isolation_level = 'REPEATABLE READ'时，哪怕只执行过一条SELECT，事务一启就持 MDL 锁 - 结合
p.HOST和p.USER定位到具体应用实例或 DBA 终端，避免误杀
用 performance_schema.metadata_locks 确认锁类型和持有者线程
SHOW PROCESSLIST 根本不显示谁在 hold MDL 锁，因为它是服务层锁。得靠 metadata_locks 表看真实状态：
先确认采集器已开：
SELECT * FROM performance_schema.setup_instruments WHERE NAME = 'wait/lock/metadata/sql/mdl';
确保 ENABLED 和 TIMED 都是 YES。再查具体锁（替换 your_db 和表名）：
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_DURATION, LOCK_STATUS, OWNER_THREAD_ID FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table';
关键判断依据：
-
LOCK_TYPE是SHARED_READ还是EXCLUSIVE，对应 DML 或 DDL 操作 -
OWNER_THREAD_ID可以反查PROCESSLIST.ID，确认是谁在持锁 - 若发现多个
SHARED_READ锁长期存在，基本可锁定是长事务或连接池未正确关闭事务
KILL QUERY 优先于 KILL，且目标必须是 blocking_pid
真正要 KILL 的不是那个显示 Waiting for table metadata lock 的线程，而是 blocking_pid 对应的持锁连接。而且优先用 KILL QUERY blocking_pid，而不是 KILL blocking_pid。
原因很实际：
-
KILL QUERY只中断当前语句，保留连接和事务上下文，可能自动触发回滚并释放 MDL 锁 -
KILL会强制断开连接，但若事务处于非自动提交模式且未显式COMMIT/ROLLBACK，InnoDB 可能延迟清理，锁释放反而更慢 - 某些场景下（如应用用了连接池），
KILL后连接可能被复用并重连，而事务状态残留，导致问题复发
复杂点在于：MDL 锁释放时机与事务生命周期强绑定，而事务状态又受隔离级别、自动提交开关、应用连接管理方式共同影响。最易被忽略的是那些 Sleep 状态却持续数小时的连接——它们不报错、不写日志、不占 CPU，却能把整张表的 DDL 堵死。
