必须查performance_schema.metadata_locks才能准确定位MDL锁持有者，因其可显示LOCK_STATUS='GRANTED'的持锁线程，而SHOW PROCESSLIST仅显示“Waiting for table metadata lock”且遗漏Sleep状态的阻塞源。
查 performance_schema.metadata_locks 才能看到谁真正在持锁
SHOW PROCESSLIST 只显示 “Waiting for table metadata lock”，但不会告诉你谁在占着不放。真正持锁的线程可能状态是 Sleep、Command 是空的、Time 很大，根本不会出现在等待列表里。
必须确认 performance_schema 已启用：SELECT @@performance_schema; 返回 1；再检查采集器是否打开：SELECT ENABLED, TIMED FROM performance_schema.setup_instruments WHERE NAME = 'wait/lock/metadata/sql/mdl';。若为 NO，先执行：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/metadata/sql/mdl';
查具体持锁者（替换 your_db 和 your_table）：SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS, PROCESSLIST_ID, PROCESSLIST_USER, PROCESSLIST_HOST 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或BEGIN后挂起的事务 -
LOCK_DURATION = 'TRANSACTION'：锁会持续到事务结束，不是语句级释放 - 重点关注
PROCESSLIST_ID，它才是要处理的目标，不是 waiting_pid
用 information_schema.innodb_trx 配合 PROCESSLIST 找出“Sleep 却 RUNNING”的悬挂事务
很多元数据锁阻塞源头不是慢查询，而是应用连接池归还了连接但没 COMMIT，或者 DBA 在客户端执行 BEGIN 后离开。这类事务在 PROCESSLIST 里是 Command = 'Sleep'，但在 innodb_trx 里仍是 trx_state = 'RUNNING'。
单查 innodb_trx 容易漏掉上下文，必须 JOIN：SELECT t.trx_id, t.trx_started, t.trx_state, p.ID, p.USER, p.HOST, p.TIME, 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为空 → 极大概率是未提交的隐式事务 -
trx_isolation_level = 'REPEATABLE READ'→ 即使只跑过一条SELECT，事务一启动就持有MDL_SHARED_READ锁 - 别只看
trx_mysql_thread_id，结合p.HOST和p.USER定位到具体服务或终端
KILL 前先确认有没有写操作，避免长回滚
直接 KILL PROCESSLIST_ID 看似快，但如果该事务已修改大量行，回滚会卡住磁盘 IO、拖慢整个实例。务必先查写入量：
SELECT trx_id, trx_state, trx_isolation_level, trx_rows_modified FROM information_schema.innodb_trx WHERE trx_mysql_thread_id = ?;
-
trx_rows_modified = 0→ 通常只是读事务，KILL安全 -
trx_rows_modified > 0→ 有未提交 DML，KILL触发回滚，耗时取决于修改行数和磁盘速度 - 更稳妥的做法是先
KILL QUERY PROCESSLIST_ID（终止当前语句），再观察事务是否自动退出；若仍 RUNNING，再KILL连接
预防比排查更重要：autocommit=1 和连接池配置是关键防线
绝大多数 MDL 阻塞不是突发故障，而是长期积累的连接管理漏洞。生产环境必须确保：
- MySQL 默认
autocommit = 1，禁止应用层全局关闭（尤其 Python 的conn.autocommit = False） - Java 连接池（如 HikariCP）设
connection-init-sql = "SET autocommit = 1"，防止复用连接继承旧事务状态 - 所有脚本结尾强制加
COMMIT或ROLLBACK，哪怕只有一条SELECT - DDL 操作前执行
SELECT * FROM sys.schema_table_lock_waits;快速扫一遍阻塞链，而不是等卡住再救火
真正难的不是查锁，而是区分哪些 Sleep 连接只是空闲、哪些是挂着事务却不声不响——后者往往藏在 PROCESSLIST 最底下，Time 超过十分钟却 State 为空，最容易被忽略。
