直接查看show engine innodb status输出中的latest detected deadlock区域即可，它完整列出两个事务的sql、锁类型、索引及持有/等待关系，是唯一有效信息，其他内容均为干扰；该日志仅保留最近一次死锁，需及时执行，且mysql 8.0.24+可通过innodb_print_all_deadlocks=on写入错误日志。
直接看 SHOW ENGINE INNODB STATUS 输出里的 LATEST DETECTED DEADLOCK 就行，它已经把两个事务的 SQL、锁类型、索引、等待/持有关系全列出来了，不需要额外查表或翻日志。
死锁日志在哪找？
执行 SHOW ENGINE INNODB STATUS 后，结果里只有一块叫 LATEST DETECTED DEADLOCK 的区域真正有用，其他全是干扰信息。这块内容默认只保留最近一次死锁，所以得在出问题后立刻执行，不能等应用重启或 MySQL 重启。
- 如果没看到这块内容，说明最近没发生死锁，或者被后续的死锁覆盖了
- MySQL 8.0.24+ 支持
innodb_print_all_deadlocks=ON写入错误日志，但线上一般不开，怕刷爆磁盘 - 不要依赖
information_schema.innodb_lock_waits查死锁原因——它只反映“当前等待”，不记录已回滚的死锁现场
怎么看懂死锁日志里的关键字段
一段典型的死锁日志会分两段描述事务 1 和事务 2，每段包含三部分：HOLDS THE LOCK(S)、WAITING FOR THIS LOCK TO BE GRANTED、TRANSACTION 信息。重点盯这三项：
-
HOLDS THE LOCK(S)：看它持有什么锁（X或S）、在哪个索引（比如idx_user_id）、哪个索引值（如0x0000000000000001或字符串哈希值） -
WAITING FOR THIS LOCK TO BE GRANTED：看它卡在哪——是等另一个事务释放 X 锁？还是等间隙锁（GAP）？注意是否出现insert intention，这是插入并发死锁的典型信号 -
TRANSACTION下的mysql thread id和query：能直接对应到应用日志里的请求 ID 和原始 SQL，别信 ORM 自动生成的别名，以这里显示的为准
常见误读和陷阱
死锁日志不是“谁先谁后”的时间线，而是环路快照。容易错判的点有：
- 看到
WAITING FOR ... X LOCK就以为是写冲突？不一定——如果等的是INSERT INTO ... SELECT场景下的间隙锁，实际可能是两个 INSERT 在抢同一段空隙 - 索引名对不上？检查是否走了隐式主键（
GEN_CLUST_INDEX），尤其是没定义主键的表，InnoDB 会自建聚簇索引，死锁日志里就显示这个 - 事务状态显示
ROLLING BACK？那是 InnoDB 已经干完的事，你看到的日志是“回滚前最后一刻”的快照，不是正在回滚中 - 同一个 SQL 出现在两个事务里？说明是并发调用，但锁顺序不同——比如一个按
id IN (1,2)更新，另一个按id IN (2,1)，InnoDB 加锁顺序取决于索引扫描路径，不是 SQL 文本顺序
真正难的不是看懂日志，而是把日志里的索引值、锁类型、SQL 条件，反推回业务逻辑里哪段代码、哪个并发路径触发了不一致的加锁顺序。这时候光靠 SHOW ENGINE INNODB STATUS 不够，得结合应用层 trace ID 和数据库慢日志里的执行计划一起交叉验证。
