应直接查看 LATEST DETECTED DEADLOCK 部分，它是最近一次死锁的完整快照，被新死锁覆盖前一直保留，发现 ERROR 1213 后须立即执行 SHOW ENGINE INNODB STATUS\G 获取；重点比对两个事务的 HOLDS THE LOCK(S) 和 WAITING FOR THIS LOCK TO BE GRANTED，结合 lock_mode 判断记录锁或间隙锁类型。
直接看 LATEST DETECTED DEADLOCK 部分，别被其他信息带偏
MySQL 的 SHOW ENGINE INNODB STATUS\G 输出很长，但真正有用的死锁现场只在 LATEST DETECTED DEADLOCK 这一块。它不是“历史记录”，而是最近一次死锁的完整快照——只要没发生新死锁，它就一直保留；一旦发生新死锁，旧内容就被覆盖。所以发现业务报错 ERROR 1213 (40001): Deadlock found when trying to get lock 后，必须立刻执行这条命令，否则信息就丢了。
常见错误现象：有人翻到 TRANSACTIONS 或 SEMAPHORES 部分反复分析，结果绕了半天没定位到冲突行；也有人误以为日志里“waiting”最多的事务就是罪魁祸首，其实 MySQL 已经回滚了它，重点要看它**为什么等**、以及另一个事务**凭什么不放锁**。
- 执行前先确认事务隔离级别：
SELECT @@transaction_isolation，RR（可重复读）下更容易出现间隙锁引发的死锁，而 RC（读已提交）会少很多锁类型 - 输出中每个事务块以
*** (1) TRANSACTION:和*** (2) TRANSACTION:开头，编号不代表执行顺序，只是日志标记 - 注意时间戳精度——例如
2025-09-24T09:11:00.008513Z，毫秒级对排查并发时序至关重要
HOLDS THE LOCK(S) 和 WAITING FOR THIS LOCK TO BE GRANTED 是关键对照组
这两个字段构成死锁链的核心证据：一个事务拿着 A 锁等着 B 锁，另一个拿着 B 锁等着 A 锁。它们不是孤立描述，必须交叉比对。
使用场景：比如你看到事务 1 的 WAITING FOR... 指向 index PRIMARY of table `maria`.`errlog_test`，而事务 2 的 HOLDS THE LOCK(S) 正好也是这个索引、同一 page no、不同 heap no 的记录锁，基本就能锁定冲突行。
-
lock_mode X locks rec but not gap表示是“记录锁（非间隙）”，说明语句走了主键或唯一索引精确匹配（如WHERE id = 2） -
lock_mode X locks gap before rec则是间隙锁，常见于范围查询（如WHERE a > 5 AND a ），这类锁最容易引发不可见的循环等待 - 十六进制的
hex 80000001对应十进制1，是主键值；hex 61是 ASCII 的a，可用于反推被锁的字段内容
用 information_schema.INNODB_TRX 补全上下文，别只信日志里的 SQL
死锁日志里的 query id 和 query 字段有时不完整，尤其是预编译语句或 ORM 自动生成的 SQL（比如 MyBatis 的 #{} 占位符未展开）。这时候得靠运行时视图补全真实意图。
性能影响：SELECT * FROM information_schema.INNODB_TRX 是轻量级查询，但频繁轮询会影响 performance_schema 开销；生产环境建议只在捕获到死锁后手动执行一次。
- 重点关注字段：
TRX_ID（对应日志里的事务 ID）、TRX_MYSQL_THREAD_ID（可关联PROCESSLIST查应用线程）、TRX_QUERY（当前执行语句）、TRX_STATE（通常是LOCK WAIT） - 配合
SELECT * FROM performance_schema.data_locks WHERE ENGINE_TRANSACTION_ID = xxx（MySQL 8.0+）能看清具体锁在哪几行、什么模式 - 如果
TRX_QUERY是NULL，说明事务处于空闲等待状态，实际卡在上一条语句的锁释放上
开启 innodb_print_all_deadlocks 要谨慎，错误日志可能爆炸
虽然把 innodb_print_all_deadlocks = ON 加进 my.cnf 能持久保存所有死锁，但默认错误日志路径（如 /var/log/mysql/error.log）很可能被其他模块高频写入。一旦高并发下每秒触发多次死锁，日志体积会指数增长，甚至撑爆磁盘。
容易踩的坑：有人开启后没配 logrotate，两周后发现日志文件超 20GB；还有人误把该参数设为 1 写成 ON，导致 MySQL 启动失败（严格模式下参数校验不通过）。
- 临时启用（重启不生效）：
SET GLOBAL innodb_print_all_deadlocks = ON，适合压测期间短期观察 - 永久配置务必加日志轮转：
log_error = /var/log/mysql/error.log+log_error_verbosity = 3（减少冗余信息） - 更稳妥的替代方案：用
tail -f /var/log/mysql/error.log | grep -i "deadlock"实时过滤，配合脚本自动抓取SHOW ENGINE INNODB STATUS快照
死锁日志本身不撒谎，但它的信息密度太高，一行 heap no 3 可能对应业务里一个没加索引的 UPDATE，一个 gap before rec 可能暴露了事务里漏掉的 SELECT ... FOR UPDATE。真正难的从来不是“看懂日志”，而是把日志里的锁行为，和你代码里那几行 SQL 的执行计划、索引选择、事务边界严丝合缝地对上。
