在MySQL 5.7中如何通过元数据锁MDL排查导致系统卡死的表DDL-mysql教程-PHP中文网

真正要kill的是blocking_pid对应的持锁连接，而非显示“waiting for table metadata lock”的等待线程；优先用kill query，通过sys.schema_table_lock_waits可直接获取阻塞链，blocking_pid为null时可能为隐式事务悬挂持锁。

在mysql 5.7中如何通过元数据锁mdl排查导致系统卡死的表ddl

查 `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 表看真实状态：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

先确认采集器已开：

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

关键判断依据：