sys.innodb_lock_waits常为空，因其仅记录瞬时发生的直接锁等待（a等b），不保留历史、不递归展示多层阻塞链（如a→b→c→d），且一旦事务超时回滚或提交，记录立即消失。
查 sys.innodb_lock_waits 为什么经常看不到阻塞链？
因为 sys.innodb_lock_waits 只展示「当前正在发生的锁等待」快照，不记录历史、不递归展开阻塞源头。一旦被阻塞事务已超时回滚，或阻塞者已提交，这条记录就消失了。更关键的是：它只显示直接等待关系（A 等 B），而真实场景中可能是 A→B→C→D 的多层阻塞，这张视图完全不体现 C 和 D。
用 sys.schema_table_lock_waits 还是 sys.innodb_lock_waits？
选 sys.innodb_lock_waits——它专为行级锁设计，字段含 blocking_trx_id 和 waiting_trx_id，可关联 information_schema.INNODB_TRX 查事务详情；schema_table_lock_waits 主要针对元数据锁（MDL），比如 ALTER TABLE 卡住 SELECT，和行锁阻塞无关。
-
innodb_lock_waits的blocking_trx_id是十六进制字符串，需转成十进制再 joinINNODB_TRX - 务必 join
INNODB_TRX两次：一次查等待事务的trx_started、trx_state，一次查阻塞事务的trx_mysql_thread_id - MySQL 8.0.26+ 才支持
sys.innodb_lock_waits中的blocking_lock_id字段，旧版本得靠INNODB_LOCKS（已弃用）或解析SHOW ENGINE INNODB STATUS
怎么一次性查出完整的阻塞链（A→B→C）？
MySQL 原生 sys 库不提供递归查询能力，必须手写自连接或用 CTE。推荐用带层级标记的 CTE（MySQL 8.0.1+ 支持）：
WITH RECURSIVE blocking_chain AS (
SELECT
r.trx_id waiting_trx_id,
r.trx_mysql_thread_id waiting_pid,
r.trx_started waiting_started,
b.trx_id blocking_trx_id,
b.trx_mysql_thread_id blocking_pid,
b.trx_started blocking_started,
1 AS level
FROM information_schema.INNODB_TRX r
JOIN information_schema.INNODB_TRX b
ON b.trx_id = r.trx_wait_started -- 注意：这里需先从 innodb_lock_waits 推出 wait_for，实际应先查锁等待再关联
WHERE r.trx_state = 'LOCK WAIT'
UNION ALL
SELECT
bc.waiting_trx_id,
bc.waiting_pid,
bc.waiting_started,
b2.trx_id,
b2.trx_mysql_thread_id,
b2.trx_started,
bc.level + 1
FROM blocking_chain bc
JOIN information_schema.INNODB_TRX b2
ON b2.trx_id = (SELECT blocking_trx_id FROM sys.innodb_lock_waits WHERE waiting_trx_id = bc.blocking_trx_id)
WHERE bc.level <p>但注意：上述 CTE 依赖 <code>sys.innodb_lock_waits</code> 的实时性，且无法处理环形阻塞（极罕见）。生产环境更稳妥的做法是先执行：<code>SELECT * FROM sys.innodb_lock_waits\G</code>，再对每个 <code>blocking_trx_id</code> 手动查其是否也在等待别的事务——别指望一条 SQL 解决所有问题。</p><h3>为什么 <code>KILL</code> 了阻塞者，等待事务还没恢复？</h3><p>常见原因有三个：</p>
- 被
KILL的线程处于Query状态但尚未真正退出，INNODB_TRX中仍显示trx_state = RUNNING，需等事务清理完成（尤其大事务 rollback 耗时长） - 等待事务本身已超时（
innodb_lock_wait_timeout默认 50 秒），自动回滚后连接断开，你看到的只是残留状态 - 阻塞者释放锁后，下一个等待者立刻抢到锁，原等待事务早已因超时失败，此时查
INNODB_TRX已无该trx_id
最有效的确认方式是：在 KILL 后立刻执行 SELECT trx_id, trx_state, trx_wait_started FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT';，看记录是否清空——别只盯着 processlist 的 Command 列。
