元数据锁（MDL）阻塞是线程卡在“Waiting for table metadata lock”的主因，应优先定位并终止持有锁的“Sleep”状态但事务未提交的连接，而非等待者；可通过sys.schema_table_lock_waits、INNODB_TRX与PROCESSLIST联查、performance_schema.metadata_locks等精准识别阻塞源与锁持有者。
看到大量线程卡在 Waiting for table metadata lock，基本可以断定是元数据锁（MDL）阻塞，不是行锁或死锁；真正要杀的不是“等待者”，而是那个安静挂着、COMMAND = 'Sleep' 却仍持有事务的连接。
查 sys.schema_table_lock_waits 快速定位阻塞链
这是 MySQL 5.7+ 最省力的入口，直接暴露谁在堵谁：blocking_pid 是持锁者，waiting_pid 是被卡住的 DDL 或查询，sql_text 甚至能显示持锁者最后执行的语句。
执行：
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就断开）在持锁
联合 INNODB_TRX 和 PROCESSLIST 找“Sleep 却 RUNNING”的悬挂事务
很多阻塞源根本不在跑 SQL，而是在连接池归还连接后，事务没提交——它在 PROCESSLIST 里是 COMMAND = 'Sleep'，但在 INNODB_TRX 里仍是 trx_state = 'RUNNING'，从 BEGIN 起就一直拿着 MDL_SHARED_READ 锁。
必须用 JOIN 查，单查 INNODB_TRX 会漏掉已断连但事务未清理的连接：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SELECT t.trx_id, t.trx_started, t.trx_state, 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;
-
trx_started时间越早越可疑；超过 5 分钟基本可判为异常 -
trx_isolation_level = 'REPEATABLE READ'时，哪怕只执行过一条SELECT，事务一启就持 MDL 锁 -
INFO为空 +TIME > 600→ 90% 是应用异常中断或忘记COMMIT
用 performance_schema.metadata_locks 确认锁类型与持有者线程
SHOW PROCESSLIST 完全不显示谁在 hold MDL 锁，因为它是服务层锁。只有 performance_schema.metadata_locks 能看到真实状态，尤其关注 LOCK_STATUS = 'GRANTED' 的行。
执行前确保采集器已开：
SELECT * FROM performance_schema.setup_instruments WHERE NAME = 'wait/lock/metadata/sql/mdl';（需
ENABLED 和 TIMED 都为 YES）
查具体锁归属（替换 your_db 和 your_table）：
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_DURATION, PROCESSLIST_ID FROM performance_schema.metadata_locks m JOIN performance_schema.threads t ON m.OWNER_THREAD_ID = t.THREAD_ID WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table' AND LOCK_STATUS = 'GRANTED';
-
LOCK_TYPE = 'SHARED_READ'表示是SELECT或mysqldump持有的读锁 -
LOCK_DURATION = 'TRANSACTION'表示该锁会持续到事务结束，不是语句级 -
PROCESSLIST_ID就是真正要处理的线程 ID，别和INNODB_TRX.trx_mysql_thread_id混用（后者在某些版本下可能滞后）
KILL CONNECTION 前必须确认事务状态与回滚风险
KILL QUERY 对 MDL 完全无效，它只终止语句，不结束事务；只有 KILL CONNECTION（即 KILL）才能切断连接、触发事务回滚、释放 MDL。但盲目 KILL 风险很大：
- 若被杀会话正处在
Rolling back状态，MDL 仍持续持有，其他 DDL 继续卡住 - 若该连接归属主从复制线程或监控采集任务，
KILL可能导致延迟飙升或指标丢失 - 大事务回滚要重放 undo log，可能耗时几十秒甚至几分钟；磁盘 I/O 压力高时，“cleaning up”阶段可能长时间卡住
安全做法是：
先查 performance_schema.threads 确认 PROCESSLIST_STATE IN ('Sleep', 'Waiting for table metadata lock') 且 PROCESSLIST_TIME > 300，再结合 INNODB_TRX 中 trx_state = 'RUNNING' 和 trx_rows_modified = 0 判断是否空转——满足这三项才考虑 KILL。
复杂点在于：锁释放不是原子操作，KILL 后立刻查 SHOW PROCESSLIST 看不到对应线程，不代表 MDL 已释放；得等回滚完成，而这个时间不可控。
