<p>必须立即执行SHOW ENGINE INNODB STATUS\G查看LATEST DETECTED DEADLOCK区块，重点比对 (1) TRANSACTION与 (2) TRANSACTION中的HOLDS THE LOCK(S)和WAITING FOR THIS LOCK TO BE GRANTED，结合lock_mode、索引名及主键值定位冲突行。</p>
怎么看懂 SHOW ENGINE INNODB STATUS 里的死锁日志
MySQL 的死锁信息不会写进 error log，只藏在 SHOW ENGINE INNODB STATUS 输出的 LATEST DETECTED DEADLOCK 区域里。执行这条命令后，重点找「*** (1) TRANSACTION」和「*** (2) TRANSACTION」这两块——它们分别代表两个互相卡住的事务，不是按时间顺序排列的，而是按 InnoDB 内部检测顺序列出来的。
每个事务块里，mysql tables in use 和 locked tables 告诉你涉及哪些表；LOCK WAIT 行说明当前在等哪个锁；最关键的是 WE WAIT FOR THIS LOCK TO BE GRANTED 后面那串 lock_mode X locks rec but not gap waiting，它告诉你锁类型（X=排他锁）、范围（rec but not gap = 记录锁，非间隙锁）、状态（waiting）；再往下翻，HELD LOCS 或 Trx id 后面的 SQL 就是真正持有锁、阻塞别人的语句。
- 别只盯着「waiting」那一行，它只是受害者，真正要查的是「holding」那一方的
SQL（通常出现在另一事务块的HELD LOCS或Trx has been waiting上方几行） - 如果看到
lock_mode X insert intention waiting，说明是插入意向锁冲突，大概率是并发 INSERT 同一个唯一键或主键重复导致的 -
Trx read view信息可忽略，对定位 SQL 没直接帮助
为什么 information_schema.INNODB_TRX 查不到死锁中的事务
死锁被检测到后，InnoDB 会立刻回滚其中一个事务（通常是 undo log 更小的那个），所以等你去查 information_schema.INNODB_TRX 时，两个事务可能都已消失——那个被选中回滚的已经没了，另一个也因异常中断而退出。这不是查询时机问题，是设计如此：死锁处理是原子动作，不留给用户“抢救”窗口。
- 想确认是否刚发生过死锁，只能靠定期抓取
SHOW ENGINE INNODB STATUS并解析LATEST DETECTED DEADLOCK段落，不能依赖实时查表 -
INNODB_TRX只能帮你发现“正在堵着但还没死锁”的长事务，比如trx_state = 'LOCK WAIT'且trx_started时间很早，这种才是潜在风险点 - 如果应用层没开启
innodb_print_all_deadlocks = ON，死锁日志只保留最近一次，历史记录直接丢弃
如何让死锁现场更容易复现和分析
生产环境死锁往往偶发且难捕获，光靠人工翻日志效率极低。最有效的做法是打开 innodb_print_all_deadlocks，把所有死锁写进 error log，并配合慢日志 + general log 做交叉比对。
- 在 my.cnf 里加一行：
innodb_print_all_deadlocks = ON，重启 MySQL（5.6.2+ 支持，无需重启也可动态设，但建议持久化） - 开启
slow_query_log并设置long_query_time = 0，这样所有执行超时的语句（包括被锁住的）都会记入慢日志，方便关联时间戳 - 避免用
general_log = ON在高流量库上长期开启，但可在疑似时段临时打开 30 秒，抓取完整 SQL 流水，注意磁盘空间和性能影响 - 死锁日志里的时间是 UTC，而慢日志默认用系统时区，比对前务必统一时区（比如都转成
SELECT NOW() AT TIME ZONE 'UTC'）
常见误判：为什么看起来是 A 语句导致死锁，实际却是 B 语句埋的雷
死锁从来不是单条 SQL 的问题，而是两条（或更多）SQL 的执行路径交叉形成的环。典型例子是：事务 1 先更新 user 表再更新 order 表，事务 2 反过来先更新 order 再更新 user——谁先拿到第一个锁，谁就大概率成为赢家，另一个变成死锁受害者。此时你看到的“导致死锁的 SQL”，其实是第二个执行、但路径相反的那条。
- 检查每条 SQL 的索引使用情况：
EXPLAIN看是否走了索引；没走索引的 UPDATE/DELETE 会锁全表或大范围记录，大幅提高死锁概率 - 注意隐式转换：比如
WHERE phone = 13800138000（phone 是 VARCHAR），会导致索引失效，进而升级为表级锁 - 批量操作尽量按主键顺序执行，避免不同事务以不同顺序访问同一组记录
死锁日志本身不带堆栈或调用链，它只告诉你“哪两条 SQL 卡住了”，但不告诉你“谁在什么时候调用了它们”。真正定位根因，得结合应用日志里的 trace_id 或 request_id，把 SQL 执行上下文还原出来——这点最容易被忽略，也最难补救。
