LATEST DETECTED DEADLOCK是定位死锁唯一有效段落，关键看“(1) WAITING FOR THIS LOCK TO BE GRANTED”和“(2) HOLDS THE LOCK(S)”两行，合起来揭示锁冲突环路；该记录仅保留最后一次，易被覆盖，需实时监控抓取。
直接看 LATEST DETECTED DEADLOCK 区域，其他全是干扰项
死锁发生后，SHOW ENGINE INNODB STATUS 是唯一能拿到现场快照的命令，但它输出很长，真正有用的就三段：LATEST DETECTED DEADLOCK、TRANSACTIONS、FILE I/O。其中只有 LATEST DETECTED DEADLOCK 能告诉你“谁卡了谁、为什么卡”，其余部分对定位死锁原因基本无用。
常见错误是扫一眼就关掉——尤其容易漏掉关键两行：*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 和 *** (2) HOLDS THE LOCK(S):。这两行才是冲突根源：一个在等锁，一个正拿着锁，合起来就是死锁环路的切片。
注意它只保留最后一次死锁记录，高频场景下极易被覆盖。不是命令失效，而是你执行得太晚。
SHOW ENGINE INNODB STATUS 看不到死锁？先确认这三件事
执行完没看到 LATEST DETECTED DEADLOCK，别急着怀疑权限或版本，先检查：
- 最近是否真发生了死锁？应用层可能已捕获
Deadlock found when trying to get lock（错误码 1213）并自动重试，DBA 没及时查，日志就被刷掉了 - 事务是否因超时回滚了？
innodb_lock_wait_timeout默认 50 秒，若等待超时后才被检测到，InnoDB 不会记为死锁，只算锁等待超时 - 是否刚重启过 MySQL？该状态是内存中的快照，重启即清空，不会持久化
所以不能等出问题再查，得配合监控：用脚本每 30 秒抓一次 SHOW ENGINE INNODB STATUS\G 输出，或监听错误日志里带 Deadlock 的行。
从死锁日志里还原真实 SQL 和锁行为的关键字段
日志里不会直接写 UPDATE users SET status = 1 WHERE id = 123，但你能从中提取出足够定位的信息：
-
TABLE: `mydb`.`orders`→ 明确库名和表名 -
index `PRIMARY`或index `idx_user_id`→ 锁在哪条索引上，说明 SQL 涉及该索引字段 -
lock_mode X locks rec but not gap→ 行锁（非间隙锁），大概率是等主键或唯一索引上的精确匹配 -
lock_mode S locks gap before rec→ 间隙锁，往往出现在范围查询（如WHERE status ）或插入前的检查 -
mysql thread id 12345和query: UPDATE ...→ 直接对应应用日志里的请求 ID 和原始 SQL，别信 ORM 自动生成的别名
特别注意 insert intention 这个信号：如果看到它出现在 WAITING FOR 行，基本可以断定是并发 INSERT 抢同一段间隙导致的死锁，和 UPDATE 冲突无关。
为什么 information_schema.innodb_lock_waits 查不到死锁原因？
因为这张表只反映“当前正在等待”的锁关系，不记录已经回滚的死锁现场。死锁发生后，InnoDB 会立刻回滚其中一个事务，等你去查 INNODB_LOCK_WAITS 时，等待关系早已消失，表里可能为空或只显示残留的旧记录。
它适合查实时锁等待（比如某个事务卡住不动了），但不适合复盘死锁。真正能回溯的，只有 LATEST DETECTED DEADLOCK 里的快照，以及开启 innodb_print_all_deadlocks=ON 后写入错误日志的完整历史。
最易被忽略的一点：死锁日志不是时间线，而是环路快照。看到两个事务都执行了同一条 SQL，不代表它们顺序一致——加锁顺序取决于索引扫描路径，而路径又受 WHERE 条件值顺序、索引选择、甚至优化器统计信息影响。这点在排查时必须反复验证。
