明确答案：大量线程State为Waiting for table metadata lock且Time>300s即可断定是MDL阻塞；需联合INNODB_TRX与PROCESSLIST查出COMMAND='Sleep'但trx_state='RUNNING'的悬挂事务，再通过SHOW ENGINE INNODB STATUS确认空转后KILL。
直接看 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;
关键判断点：
-
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>中断当前语句；若仍卡住，再KILL <thread_id>
升级 MySQL 8.0 后必须调 wait_timeout 和 interactive_timeout
MySQL 8.0 默认 wait_timeout=28800（8 小时），对现代应用完全不合理。连接池长期复用一个连接，但应用层忘了 commit，这个连接就挂着事务一直不释放 MDL 锁。
生产环境建议设为：
-
wait_timeout = 300（5 分钟） interactive_timeout = 300- 同时在应用侧确保所有数据库操作后显式
commit或rollback，不能依赖连接关闭自动回滚
真正难处理的不是锁本身，而是那些 trx_state = 'RUNNING' 却 INFO 为空、STATE 为 Sleep、又找不到任何业务上下文的线程——它们往往来自旧版本 SDK 或未规范管理的定时任务，排查时得翻代码日志，而不是只盯数据库。
