MySQL performance_schema data_lock_waits 怎么还原锁冲突：阻塞链与处理顺序

线上订单写入突然卡住时，先别急着杀掉最慢的连接。InnoDB 的锁等待通常至少涉及一个正在申请锁的事务和一个持有锁的事务，performance_schema.data_lock_waits 正好记录这条依赖关系；把它和 data_locks、线程当前语句连起来，才能知道该处理谁。

排查重点不是“哪个线程最慢”，而是先找出请求锁、阻塞锁和对应业务对象，再根据事务是否仍在工作决定等待、提交还是回滚。

先把锁等待现场还原成一条链

data_lock_waits 不是“所有锁的列表”，而是阻塞关系表：它展示哪个锁请求被哪个已持有的锁挡住。官方文档将它描述为 data_locks 中请求锁与已持有锁之间的多对多关系，因此查到一行时，左边是等待者，右边是阻塞者。

现场先执行下面这条查询，只取当前存在的等待关系。不要把它保存成长期业务表；锁信息变化很快，重复查询比一次导出更可靠。

SELECT
    w.ENGINE,
    w.REQUESTING_ENGINE_TRANSACTION_ID AS waiting_trx,
    w.REQUESTING_THREAD_ID AS waiting_thread,
    w.BLOCKING_ENGINE_TRANSACTION_ID AS blocking_trx,
    w.BLOCKING_THREAD_ID AS blocking_thread,
    w.REQUESTING_ENGINE_LOCK_ID AS waiting_lock_id,
    w.BLOCKING_ENGINE_LOCK_ID AS blocking_lock_id
FROM performance_schema.data_lock_waits AS w\G

用 data_locks 找到真正冲突的对象

只看事务 ID 还不够。把两个锁 ID 分别连到 data_locks.ENGINE_LOCK_ID，才能看到 OBJECT_SCHEMA、OBJECT_NAME、INDEX_NAME、LOCK_TYPE 与 LOCK_MODE。下面的写法保留等待方和阻塞方两组字段，排障时不容易把方向看反。

SELECT
    w.REQUESTING_THREAD_ID AS waiting_thread,
    wl.OBJECT_SCHEMA AS waiting_schema,
    wl.OBJECT_NAME AS waiting_table,
    wl.INDEX_NAME AS waiting_index,
    wl.LOCK_MODE AS waiting_mode,
    w.BLOCKING_THREAD_ID AS blocking_thread,
    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 wl
  ON wl.ENGINE_LOCK_ID = w.REQUESTING_ENGINE_LOCK_ID
 AND wl.ENGINE = w.ENGINE
JOIN performance_schema.data_locks AS bl
  ON bl.ENGINE_LOCK_ID = w.BLOCKING_ENGINE_LOCK_ID
 AND bl.ENGINE = w.ENGINE;

如果两边对象、索引或锁模式不符合预期，先重新采样。MySQL 官方提醒，INNODB_TRX、data_locks 和 data_lock_waits 反映的是快速变化的内部状态，几张表之间不保证在同一个瞬间完全一致。

线程 ID 要继续追到当前 SQL

REQUESTING_THREAD_ID 和 BLOCKING_THREAD_ID 是 Performance Schema 线程 ID，不等同于应用日志里的订单号，也不应直接当作可终止的连接编号。先查看线程所属账号、主机和进程列表 ID，再读当前语句。

SELECT
    t.THREAD_ID,
    t.PROCESSLIST_ID,
    t.PROCESSLIST_USER,
    t.PROCESSLIST_HOST,
    es.EVENT_NAME,
    es.SQL_TEXT,
    es.TIMER_WAIT
FROM performance_schema.threads AS t
LEFT JOIN performance_schema.events_statements_current AS es
  ON es.THREAD_ID = t.THREAD_ID
WHERE t.THREAD_ID IN (/* waiting_thread */, /* blocking_thread */);

等待者的当前语句能说明它想改什么，阻塞者的当前语句则帮助判断它是否只是忘了结束事务。若 SQL_TEXT 为空，不能据此认定线程安全：它可能已经执行完语句但事务仍未 COMMIT。

处理顺序：先确认业务，再决定 COMMIT 还是 ROLLBACK

真正需要终止会话时，使用 PROCESSLIST_ID 对应的连接处理，并记录原因、时间和业务单号。BLOCKING_THREAD_ID 只是 Performance Schema 的观察标识；不要把它直接拼进管理命令。已经确认事务异常且无法让应用正常收尾时，才进入回滚路径。

常见坑：为什么查到了等待，却不能立刻下结论

相关问题

data_lock_waits 为空，是否代表没有锁问题？

不一定。它主要回答数据锁依赖，元数据锁要看 metadata_locks；同时也可能刚好错过了快速变化的等待现场。

阻塞线程的 SQL_TEXT 为空怎么办？

结合事务状态和连接空闲时间判断。语句结束不等于事务结束，重点是确认是否仍持有锁以及业务是否允许收尾。

为什么不直接调大 innodb_lock_wait_timeout？

超时参数只能改变等待多久，不能消除冲突。先还原阻塞链，才能判断是事务过长、访问顺序不一致，还是连接归还前漏了提交。

data_locks 查询结果会不会和等待关系对不上？

会出现短暂不一致。官方说明这些表是快速变化的内部视图，异常现场应连续采样并记录查询时间，而不是把三张表当成事务快照。

把排障查询固化成可复用检查单

1. 先查 data_lock_waits，保存等待事务、阻塞事务、请求锁 ID 和阻塞锁 ID。
2. 回连 data_locks，核对库、表、索引、锁类型和模式。
3. 通过 performance_schema.threads 获取连接归属，再读 events_statements_current。
4. 让业务确认阻塞事务的收尾方式，优先正常 COMMIT；确认失效后再走 ROLLBACK 或终止连接。
5. 复查等待是否消失，并把事务边界、访问顺序和连接释放方式补进复盘。

这套顺序的价值在于把“数据库卡住了”拆成可验证的请求方、持有方和对象。下一次报警再来时，先留下关系链，再处理连接，误伤会少很多。