如何在MySQL中排查Metadata Lock导致的应用卡死？-mysql教程-PHP中文网

元数据锁（MDL）阻塞是线程卡在“Waiting for table metadata lock”的主因，应优先定位并终止持有锁的“Sleep”状态但事务未提交的连接，而非等待者；可通过sys.schema_table_lock_waits、INNODB_TRX与PROCESSLIST联查、performance_schema.metadata_locks等精准识别阻塞源与锁持有者。

如何在mysql中排查metadata lock导致的应用卡死？

看到大量线程卡在 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 会漏掉已断连但事务未清理的连接：

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' 的行。

执行前确保采集器已开：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

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 已释放；得等回滚完成，而这个时间不可控。