如何排查MySQL InnoDB死锁日志-mysql教程-PHP中文网

show engine innodb status仅返回最近一次死锁的完整快照，位于latest detected deadlock区块，含事务id、holds/waiting锁信息及被回滚事务；历史死锁会被覆盖，需配合innodb_print_all_deadlocks=on写入错误日志方可追溯。

如何排查mysql innodb死锁日志

SHOW ENGINE INNODB STATUS 能看到什么

它只返回最近一次死锁的完整上下文，不是历史记录也不是实时流。关键信息全在 LATEST DETECTED DEADLOCK 区块里，包括两个事务的 SQL、各自持有的锁（HOLDS THE LOCK(S)）、等待的锁（WAITING FOR THIS LOCK TO BE GRANTED），以及最终被回滚的是哪个事务（WE ROLL BACK TRANSACTION (X)）。

常见误区是以为执行一次就能捕获所有死锁——其实只要中间发生过另一次死锁，前一次就被覆盖了。生产环境必须配合其他方式补位。

为什么 innodb_print_all_deadlocks=ON 是刚需

默认情况下 MySQL 只记最后一次，等于把黑匣子设成“覆盖式录音”。开启后，所有死锁都会追加写入错误日志（log_error 指定路径），便于事后回溯和统计频次。

临时开启：SET GLOBAL innodb_print_all_deadlocks = ON;
永久生效：在 my.cnf 的 [mysqld] 段落加 innodb_print_all_deadlocks = 1
验证是否生效：SHOW VARIABLES LIKE 'innodb_print_all_deadlocks'; 返回 ON 或 1

注意：该变量不支持会话级设置，只能全局生效；且开启后日志体积会增大，但远小于锁等待堆积带来的风险。

MySQL

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

下载

performance_schema.data_lock_waits 怎么查实时阻塞

MySQL 8.0+ 提供了更细粒度的锁等待视图，比 INNODB_LOCK_WAITS 更可靠（后者在高并发下可能为空）。它能直接关联等待方与持有方的线程 ID 和 SQL：

SELECT 
  r.trx_id AS waiting_trx_id,
  r.trx_query AS waiting_query,
  b.trx_id AS blocking_trx_id,
  b.trx_query AS blocking_query
FROM performance_schema.data_lock_waits w
JOIN information_schema.INNODB_TRX r ON r.trx_id = w.WAITING_TRX_ID
JOIN information_schema.INNODB_TRX b ON b.trx_id = w.BLOCKING_TRX_ID;

这个查询不依赖死锁是否已触发，只要存在锁等待（哪怕还没升级为死锁），就能捞出来。适合做监控告警的底表。

死锁日志里最易看错的三处

日志字段密集、缩进混乱，人工阅读容易跳行漏判：

*** (1) TRANSACTION 和 *** (2) TRANSACTION 不代表执行先后顺序，只表示解析时的编号；真正顺序得看 ACTIVE X sec 时间戳
lock_mode X locks rec but not gap 表示记录锁（非间隙锁），而 lock_mode X locks gap before rec 才是间隙锁——后者更容易引发连锁等待
space id 和 page no 对应具体数据页，可用于结合 INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES 定位哪张表哪条索引，但多数场景只需关注 table `db`.`tbl` 和 index PRIMARY 这类显式标识

真正难的不是读日志，而是把两条 SQL 放回业务逻辑里，还原出它们为何以相反顺序访问相同资源——那才是根因所在。