必须先定位持锁会话再精准终止：kill query中断语句，kill connection断连；启用performance_schema采集器后，用sys.schema_table_lock_waits定位阻塞源，结合innodb_trx与processlist识别悬挂事务。
直接杀错线程会让阻塞更久，必须先定位真正持锁的会话再精准终止——KILL QUERY 和 KILL CONNECTION 行为完全不同，选错等于雪上加霜。
查不到持锁线程？先确认 performance_schema 真在干活
很多环境里 performance_schema 默认开启但关键采集器被关着，查 metadata_locks 表永远为空。不是没锁，是根本没记。
-
SELECT @@performance_schema;必须返回1，否则整个机制不启动 - 执行
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/lock/metadata/sql/mdl';，这是 MDL 锁的“开关” - 执行
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'global_instrumentation' OR NAME LIKE 'thread_instrumentation';，否则线程信息不会入库 - 注意：这些配置只对新建立的连接生效，已存在的连接不会补录历史锁状态
sys.schema_table_lock_waits 是最快定位阻塞源的入口
这是 MySQL 5.7+ 最直接的诊断视图，它把谁堵谁一次性列清楚：blocking_pid 是持锁者，waiting_pid 是受害者。
- 执行
SELECT * FROM sys.schema_table_lock_waits\G，优先看blocking_pid非NULL的行 - 如果返回为空，先检查上面提到的采集器是否启用；
blocking_pid为NULL不代表没锁，很可能是隐式事务（如BEGIN后只跑了一条SELECT就断开）在持锁 -
sql_text字段能告诉你持锁者最后执行了什么语句，比盲猜SHOW PROCESSLIST靠谱得多
持锁者是 Sleep 连接？大概率是应用忘记 COMMIT 或异常中断
大量阻塞源不是正在跑 SQL 的线程，而是那种 COMMAND = 'Sleep'、STATE 为空、TIME > 300 且 INFO 为空的连接——它大概率 BEGIN 了却没 COMMIT，从启动就一直占着 MDL_SHARED_READ 锁。
- 用这个 JOIN 查询找“悬挂事务”：
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'时，哪怕只执行过一条SELECT，事务一启就持 MDL 锁 -
INFO为空 +TIME > 600→ 90% 是应用异常中断或忘记COMMIT
KILL QUERY 还是 KILL CONNECTION？看持锁者有没有改数据
不能无脑 KILL，必须结合事务状态判断：
- 如果持锁者是长
SELECT或空闲连接（Command = 'Sleep'且Time > 60），用KILL CONNECTION：锁绑在连接生命周期上，语句早结束了但连接还挂着 - 如果持锁者正在执行大事务（比如
UPDATE改了几十万行但还没提交），优先用KILL QUERY：它只中断当前语句，事务仍存在但 MDL 锁立即释放；而KILL CONNECTION会触发回滚，回滚过程本身持续持有MDL_EXCLUSIVE锁，阻塞时间可能翻倍 -
KILL QUERY没用？说明事务还在跑，MDL 锁照旧持有——必须用KILL CONNECTION强制断连
最危险的盲区是：以为 INNODB_TRX 里没事务就安全了。MDL 锁可以由隐式事务、未关闭的连接、甚至失败的查询残留持有，光看事务表会漏掉一半问题。
