MySQL出现死锁问题如何快速定位_分析innodb_lock_waits表信息-mysql教程-PHP中文网

查不到死锁记录是因为innodb检测到死锁后立即回滚事务并清理innodb_lock_waits中的等待关系，该表仅为瞬时快照；应优先查看show engine innodb status中的latest detected deadlock段或开启innodb_print_all_deadlocks=on捕获日志。

mysql出现死锁问题如何快速定位_分析innodb_lock_waits表信息

查 `INFORMATION_SCHEMA.INNODB_LOCK_WAITS` 前先确认是否真有死锁

MySQL 不会把所有锁等待都记为死锁，只有被 InnoDB 主动检测并回滚掉的事务才会写入 INNODB_LOCK_WAITS。所以你查不到记录，不等于没锁争用——可能只是普通锁等待（超时后报 Lock wait timeout exceeded），或者死锁刚发生就被清掉了。

真正要定位死锁，优先看错误日志里的死锁详情（SHOW ENGINE INNODB STATUS\G 输出的 LATEST DETECTED DEADLOCK 段），它包含事务 ID、SQL、持有/等待的锁、回滚决策，比 INNODB_LOCK_WAITS 更直接。

INNODB_LOCK_WAITS 是“快照视图”，只反映查询时刻的等待链，不保留历史
该表在 MySQL 8.0.1+ 才默认启用；5.7 需确保 innodb_status_output_locks=ON 且启用了 performance_schema
字段如 REQUESTING_TRX_ID 和 BLOCKING_TRX_ID 是十六进制字符串，需转成十进制才能关联 INNODB_TRX 表

用 `INNODB_TRX` + `INNODB_LOCKS` + `INNODB_LOCK_WAITS` 连查还原死锁现场

单看 INNODB_LOCK_WAITS 只能知道谁在等谁，没法看到 SQL 和锁类型。必须三表 JOIN 才能拼出完整上下文：

MySQL

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

下载

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
FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS w
JOIN INFORMATION_SCHEMA.INNODB_TRX b ON b.trx_id = w.BLOCKING_TRX_ID
JOIN INFORMATION_SCHEMA.INNODB_TRX r ON r.trx_id = w.REQUESTING_TRX_ID;

INNODB_LOCKS 表在 MySQL 8.0.24+ 已废弃，改用 performance_schema.data_locks，但日常排查仍可依赖上面三表组合
如果 blocking_query 为 NULL，说明阻塞方是隐式锁（比如唯一索引冲突导致的插入意向锁）或已提交/回滚，此时需结合 INNODB_LOCKS（或 8.0+ 的 data_locks）查锁对象
注意 trx_state 字段：阻塞方若为 LOCK WAIT，说明它自己也在等别的锁，可能是锁链而非根因

为什么 `INNODB_LOCK_WAITS` 查不到刚发生的死锁？

因为 InnoDB 在检测到死锁后，会立刻选择一个事务回滚，并清理其持有的锁和对应记录——包括从 INNODB_LOCK_WAITS 中删除该等待关系。所以你执行查询时，很可能已经“人去楼空”。

死锁日志（SHOW ENGINE INNODB STATUS）是唯一带时间戳、不可篡改的证据，务必第一时间捕获
生产环境建议开启 innodb_print_all_deadlocks=ON，把每次死锁追加写入 error log，避免被后续 SHOW ENGINE 覆盖
performance_schema 的 events_statements_history_long 表可回溯线程最近执行的 SQL，配合线程 ID 能定位到触发死锁的具体语句

别只盯着锁表，先看业务 SQL 是否顺序错乱

90% 的死锁源于应用层未按固定顺序访问多张表或多个索引。比如事务 A 先更新 users 再更新 orders，事务 B 反过来，就极易形成环路。

检查是否有 UPDATE ... WHERE 语句缺失索引，导致全表扫描加锁（行锁升级为表锁风险）
批量更新尽量用主键 or 索引列 in-list，避免非唯一索引范围扫描引发间隙锁冲突
长事务（trx_state='RUNNING' 且 trx_started 很早）会拖住锁不放，是死锁温床，监控时重点关注 trx_started 和 trx_duration

死锁不是配置问题，是并发逻辑暴露了数据访问顺序的脆弱性。锁表信息只是线索，真正要改的是 SQL 执行路径和事务边界。