如何排查MySQL中由Metadata Lock导致的表死锁问题？-mysql教程-PHP中文网

明确答案：大量线程state为waiting for table metadata lock且time>300s即可断定是mdl阻塞；需联合innodb_trx与processlist查出command='sleep'但trx_state='running'的悬挂事务，再通过show engine innodb status确认空转后kill。

如何排查mysql中由metadata lock导致的表死锁问题？

直接看 `PROCESSLIST` 里卡在 `Waiting for table metadata lock` 的线程

这不是“疑似”，而是最明确的信号。只要看到大量线程的 STATE 列是 Waiting for table metadata lock，基本可以断定是 MDL 阻塞，不是行锁或间隙锁问题。这时候别急着查死锁日志——MDL 死锁不会进 LATEST DETECTED DEADLOCK，它压根不走 InnoDB 的死锁检测路径。

执行 SHOW FULL PROCESSLIST; 后重点关注：

TIME 值特别大（比如 > 300 秒）且 STATE 是 Waiting for table metadata lock 的线程，它们是被堵住的“受害者”
同时找那些 COMMAND 是 Sleep、STATE 是空或 NULL、但 TIME 也很大（> 600 秒）的线程——它们才是真正的“元凶”，大概率挂着未提交事务
注意 INFO 列是否为空：空值 + 长 TIME 是典型“连接池归还了但没 commit”的表现

联合查 `INNODB_TRX` 和 `PROCESSLIST` 找悬挂事务

单查 INNODB_TRX 会漏掉那种已断开但事务没清理干净的连接（尤其用连接池时）。必须用 JOIN 把两张表串起来，才能揪出 COMMAND = 'Sleep' 但 trx_state = 'RUNNING' 的线程。

推荐这个查询：

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;

关键判断点：

MySQL

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

下载

trx_started 时间越早，挂得越久，优先处理
trx_isolation_level 是 REPEATABLE READ 的话，从 BEGIN 就持有了 MDL_SHARED_READ，哪怕只执行过一条 SELECT 也会阻塞 ALTER TABLE
如果 INFO 为空且 TIME > 600，90% 是应用异常或忘记 commit

杀之前先用 `SHOW ENGINE INNODB STATUS\G` 确认是否真“空转”

别一看到线程 ID 就 KILL。有些线程虽然 STATE 是 Sleep，但可能刚执行完大事务正准备提交，或者正在做 binlog 写入——误杀会导致主从不一致或数据丢失。

安全确认步骤：

从上一步查出的 trx_id，在 SHOW ENGINE INNODB STATUS\G 输出里搜索对应事务段
看 mysql tables in use 和 locked tables 是否都为 0：是 → 基本没在干活，可 KILL
看 STATE 在 PROCESSLIST 中是否为 Starting authentication 或 Waiting for table metadata lock：这类基本僵死，可优先处理
优先执行 KILL QUERY <thread_id></thread_id> 中断当前语句；若仍卡住，再 KILL <thread_id></thread_id>