查不到阻塞源是因为真正持锁线程在PROCESSLIST中显示为Command='Sleep'、State为空、Time很大，但在INNODB_TRX中trx_state='RUNNING'且trx_query IS NULL；必须通过INNODB_TRX和metadata_locks联合定位，并优先执行KILL QUERY再观察，避免直接KILL引发回滚阻塞。
查不到阻塞源？别只看SHOW PROCESSLIST
真正持锁的线程在PROCESSLIST里往往显示为Command = 'Sleep'、State为空、Time值很大（比如 1800 秒），但它在INNODB_TRX中仍为trx_state = 'RUNNING'。这是典型的“事务已启动、语句早执行完、但没提交”状态，MDL锁从BEGIN那一刻起就挂着不动。
必须查information_schema.INNODB_TRX，按trx_started倒序，重点筛：
- trx_query IS NULL
- trx_state = 'RUNNING'
- trx_autocommit = 0
再用performance_schema.metadata_locks确认该线程是否对目标表持有LOCK_TYPE = 'SHARED_READ'或'SHARED_WRITE'
KILL之前为什么必须先KILL QUERY
对一个空转事务直接KILL <code>thread_id会触发完整回滚，风险很高：
- 若事务已写入大量 undo，回滚本身可能耗时数分钟，期间仍阻塞 DDL
- 连接池复用场景下，强制断连可能引发重连风暴
- ORM 框架（如 Hibernate）可能残留脏状态
更稳妥的做法是分两步：
- 先执行KILL QUERY <code>thread_id（对 Sleep 连接虽无效，但可排除它正在执行长查询的可能）
- 等待 10–20 秒，若状态未变，再执行KILL <code>thread_id
- 若SHOW ENGINE INNODB STATUS\G中对应trx_id的mysql tables in use和locked tables均为 0，基本可判定无实际操作，可安全终止
MySQL 8.0 的wait_timeout默认值是隐患源头
MySQL 8.0 默认wait_timeout = 28800（8 小时），而旧版 5.7 在连接空闲超时后常被自动断开。升级后这个宽松设置会让悬挂事务“睡得更久、锁得更死”。
必须调整：
- 全局设wait_timeout = 300（5 分钟）
- 同步设interactive_timeout = 300
- 应用层连接池也要配匹配的 idleTimeout（如 HikariCP 的connection-timeout）
- Python/Java 客户端（pymysql、aiomysql）默认autocommit=False，务必确保每次查询后显式commit()或rollback()
ALTER TABLE卡住不等于一定要杀连接
ALTER TABLE需要MDL_EXCLUSIVE锁，但它与任何已有 MDL 锁（哪怕只是SELECT带来的SHARED_READ）都互斥。盲目 KILL 可能让问题更糟——回滚过程本身持续持锁。
优先尝试：
- 检查是否可用ALGORITHM=INSTANT（仅限ADD COLUMN、RENAME COLUMN、SET DEFAULT）
- 对非关键表，用pt-online-schema-change绕过 MDL
- DDL 前主动查performance_schema.metadata_locks，确认无LOCK_STATUS = 'PENDING'再执行
- 长事务排查要快：一条 SQL 就能串起线索：SELECT trx_id, trx_mysql_thread_id, trx_started FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5
最易被忽略的是：MDL 锁等待本身不报错，只表现为查询卡在Waiting for table metadata lock状态。你看到的“慢”，不是语句执行慢，而是锁兼容性规则在生效——这点不厘清，所有排查都会跑偏。
