如何在MySQL中监控innodb_lock_waits表的锁等待链路-mysql教程-PHP中文网

直接查innodb_lock_waits只能看到“当前一跳”等待关系，因其仅记录实时的阻塞与被阻塞事务配对，不保存历史、不递归展开、不关联sql或锁资源细节；需联合innodb_trx、innodb_locks（5.7）或performance_schema.data_locks（8.0+）及data_lock_waits多表join，并递归追溯blocking_trx_id才能还原完整锁等待链路。

如何在mysql中监控innodb_lock_waits表的锁等待链路

为什么直接查 `innodb_lock_waits` 只能看到“当前一跳”，看不到完整链路

INFORMATION_SCHEMA.INNODB_LOCK_WAITS 是一张视图，它只记录「正在发生的锁等待」的配对关系：一个被阻塞事务（BLOCKING_TRX_ID）和一个阻塞者事务（REQUESTING_TRX_ID）。它不保存历史、不递归展开、也不关联事务正在执行的 SQL 或持有锁的资源细节。所以单查这张表，你只能看到「A 等 B」，但不知道 B 为什么卡住——B 可能也在等 C，C 又在等 D……链路断在这里。

必须关联 `INNODB_TRX`、`INNODB_LOCKS`（MySQL 5.7）或 `INNODB_LOCKS`/`INNODB_LOCK_WAITS`（MySQL 8.0+）才能拼出链路

真实链路还原依赖三张表联动：

INNODB_TRX：提供每个活跃事务的 ID（TRX_ID）、状态（TRX_STATE）、开始时间、正在执行的 SQL（TRX_QUERY）、锁等待开始时间（TRX_WAIT_STARTED）
INNODB_LOCKS（5.7）或 performance_schema.data_locks（8.0+）：告诉你每个事务持有哪些锁（行锁、间隙锁、表锁），锁在哪张表哪个索引哪条记录上
INNODB_LOCK_WAITS：把「谁在等谁」这个边连起来

关键操作是用 TRX_ID 做多层 JOIN，并递归向上追溯 BLOCKING_TRX_ID 的持有者——但 MySQL 原生不支持递归 CTE（直到 8.0.14+ 才有 WITH RECURSIVE），所以常用做法是写存储过程或用客户端脚本循环查询。简单起见，先用两层 JOIN 抓出「一级等待 + 阻塞者信息」：

SELECT 
  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,
  r.trx_query waiting_query,
  b.trx_id blocking_trx_id,
  b.trx_mysql_thread_id blocking_thread,
  b.trx_query blocking_query,
  b.trx_started blocking_start_time
FROM INFORMATION_SCHEMA.INNODB_TRX r
INNER JOIN INFORMATION_SCHEMA.INNODB_LOCK_WAITS w ON r.trx_id = w.REQUESTING_TRX_ID
INNER JOIN INFORMATION_SCHEMA.INNODB_TRX b ON b.trx_id = w.BLOCKING_TRX_ID;

MySQL 8.0 中 `data_locks` 和 `data_lock_waits` 替代了旧表，字段语义更清晰但需注意权限与开关

8.0 默认禁用 performance_schema 的数据锁采集，即使开了，data_locks 和 data_lock_waits 也要求 performance_schema 启用且相关消费者开启：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

确认已启用：SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE 'global_instrumentation' OR NAME LIKE 'thread%';，确保对应列为 YES
启用锁采集：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'NO' WHERE NAME = 'transaction';（实际只需开 wait/lock% 类仪器，但 transaction 是基础）
8.0 的 data_lock_waits 表中，BLOCKING_ENGINE_LOCK_ID 和 REQUESTING_ENGINE_LOCK_ID 是字符串 ID，需 JOIN data_locks.LOCK_ID 才能拿到具体表名、索引、记录等信息

常见错误：查 data_lock_waits 返回空，不是没锁等待，而是 performance_schema 没开锁采集；或者开了但没重启线程（新连接才生效）。

真正要监控链路，得定时采样 + 构建等待图，不能只靠一次查询

锁等待是瞬态现象，可能几百毫秒就结束。单次查询大概率漏掉。生产环境建议：

用脚本（Python/Shell）每 1–2 秒执行一次上面的 JOIN 查询，输出到日志文件，带时间戳
把结果按 waiting_trx_id 聚合，追踪同一事务是否持续等待、等待对象是否变化（比如从等 X 变成等 Y，说明 X 释放了但 Y 接上了）
结合 SHOW PROCESSLIST 和 INNODB_TRX.TRX_STATE = 'LOCK WAIT' 过滤出真正在等锁的线程，避免把空闲事务误判为阻塞源
注意：长时间 TRX_STATE = 'RUNNING' 却持有大量锁，往往是未提交事务（autocommit=OFF 且忘了 COMMIT），这才是根因，不是锁机制问题

链路深度超过 3 层时，人工分析容易混乱。这时候该看的是最上游那个「不等别人、只被等」的事务——它大概率拿着锁却不提交，或者执行了超长更新卡在某条慢 SQL 上。盯住它，比追十层等待更有用。