MySQL 锁等待定位事务锁等待链的实现方法

线上接口突然变慢时，先别把所有慢 SQL 都归因于索引。若线程处在锁等待，真正需要回答的是：谁在等待、等待哪把锁、谁持有这把锁、锁落在哪张表或哪个索引上。MySQL 8.4 可以用 performance_schema.data_lock_waits 还原等待关系，再用 data_locks 补齐锁对象，最后把事务 ID 映射回会话。

先从 data_lock_waits 还原谁在等谁

data_lock_waits 是入口。它不是一行一行描述完整锁，而是用请求侧和阻塞侧的锁 ID 表示依赖关系：REQUESTING_ENGINE_LOCK_ID 指向等待中的请求，BLOCKING_ENGINE_LOCK_ID 指向当前持有并造成阻塞的锁。两侧的事务 ID 和线程 ID 也会同时出现。

SELECT
  w.REQUESTING_ENGINE_TRANSACTION_ID AS waiting_trx,
  w.BLOCKING_ENGINE_TRANSACTION_ID AS blocking_trx,
  w.REQUESTING_THREAD_ID AS waiting_thread,
  w.BLOCKING_THREAD_ID AS blocking_thread
FROM performance_schema.data_lock_waits AS w; -- 先取出等待与阻塞两侧的关联

如果没有返回行，只能说明查询时刻没有被记录的 data lock wait，不能证明业务没有锁问题。等待可能刚好结束，也可能是元数据锁、应用层队列或连接池拥塞，不属于这张表的范围。

用 data_locks 把等待关系落到具体锁对象

拿到两侧锁 ID 后，分别连接 data_locks.ENGINE_LOCK_ID。排查时重点看 OBJECT_SCHEMA、OBJECT_NAME、INDEX_NAME、LOCK_TYPE、LOCK_MODE 和 LOCK_STATUS。InnoDB 中等待侧通常是 WAITING，持有侧通常是 GRANTED；表锁与记录锁的判断要结合 LOCK_TYPE，不要只看表名。

SELECT
  w.REQUESTING_ENGINE_TRANSACTION_ID AS waiting_trx,
  rl.OBJECT_SCHEMA AS waiting_schema,
  rl.OBJECT_NAME AS waiting_table,
  rl.INDEX_NAME AS waiting_index,
  rl.LOCK_TYPE AS waiting_type,
  rl.LOCK_MODE AS waiting_mode,
  bl.OBJECT_SCHEMA AS blocking_schema,
  bl.OBJECT_NAME AS blocking_table,
  bl.INDEX_NAME AS blocking_index,
  bl.LOCK_MODE AS blocking_mode
FROM performance_schema.data_lock_waits AS w
JOIN performance_schema.data_locks AS rl
  ON rl.ENGINE_LOCK_ID = w.REQUESTING_ENGINE_LOCK_ID
 AND rl.ENGINE = w.ENGINE -- 请求锁 ID 连接等待侧明细
JOIN performance_schema.data_locks AS bl
  ON bl.ENGINE_LOCK_ID = w.BLOCKING_ENGINE_LOCK_ID
 AND bl.ENGINE = w.ENGINE; -- 阻塞锁 ID 连接持有侧明细

这一步的结果只回答“哪类对象发生冲突”。如果索引字段为空、锁数据为空或关系突然减少，不要立即下结论；锁记录可能随事务提交、回滚或页面离开缓冲池而变化。

把事务链映射回会话和最后一条 SQL

锁 ID 能说明对象，却不一定能说明业务来源。继续用事务 ID 连接 information_schema.innodb_trx，可看到事务状态、开始时间、等待开始时间和 trx_mysql_thread_id。再把这个线程 ID 与 performance_schema.threads.THREAD_ID 或会话信息对应起来，才能判断连接来自哪个用户和主机。

阻塞事务的当前 SQL 为空并不稀奇：它可能刚执行完一条更新，但还没有提交。此时可以按线程查看 events_statements_history 的最近语句；也可以先读 sys.innodb_lock_waits，它是对等待链的便捷汇总视图。

按短间隔复查后再决定处置动作

锁信息属于快速变化的内部数据，多个表之间也可能在同一次查询中出现轻微不同步。实战中建议保存第一次的等待事务、阻塞事务和对象三元组，短间隔重查：关系仍在且阻塞事务未提交，才进入应用确认、提交或回滚决策；关系已消失，则记录为已恢复，继续查下一次采样，不要凭旧线程号杀连接。

常见问题

为什么 data_lock_waits 有线程却找不到当前 SQL？

线程可以保留事务而暂时没有正在执行的语句；当前查询为空不等于事务已经提交，结合事务状态和历史语句判断。

只查 data_locks 能不能得到完整等待链？

不能。data_locks 展示锁持有和请求明细，等待者与阻塞者的对应关系应由 data_lock_waits 提供。

查不到等待行时是否可以直接结束排查？

不可以。先区分数据锁、元数据锁和应用层拥塞，再用短间隔采样确认问题是否已经自行消失。