应立即执行SHOW ENGINE INNODB STATUS，定位--- LATEST DETECTED DEADLOCK ---段内两个事务块，结合LOCK WAIT、HELD LOCKS及WAITING FOR THIS LOCK TO BE GRANTED分析锁冲突，并开启innodb_print_all_deadlocks=ON持久化记录以供追溯。
死锁报错 ERROR 1213 (40001): Deadlock found when trying to get lock 怎么看日志定位冲突SQL
MySQL 检测到死锁后，不会直接告诉你哪两条 SQL 冲突了，而是把最近一次死锁的完整上下文写进 SHOW ENGINE INNODB STATUS 输出里。这个输出是排查唯一可靠入口，但内容杂乱、字段隐晦，容易看漏关键行。
- 输出中真正有用的部分被包裹在
--- LATEST DETECTED DEADLOCK ---分隔符之间，前后全是干扰信息 - 每个事务块以
<strong><em> (1) TRANSACTION</em></strong>和(2) TRANSACTION标识，注意编号不代表执行先后，只表顺序 - 关键字段是
mysql tables in use（涉及哪些表）、LOCK WAIT（谁在等锁）、HELD LOCKS（谁持有什么锁）、WAITING FOR THIS LOCK TO BE GRANTED（等哪个锁） - 最后一段
WE ROLL BACK TRANSACTION (1)表示 InnoDB 主动回滚了哪个事务（通常是加锁少、代价小的那个）
别依赖错误日志里的简短报错行——它只告诉你“发生了”，不告诉你“为什么”。必须立刻执行 SHOW ENGINE INNODB STATUS，且要在死锁刚发生后马上查，因为该命令只保留最后一次死锁记录。
从 SHOW ENGINE INNODB STATUS 中提取出真实冲突的 SQL 语句
InnoDB 不会原样打印你执行的 SQL，而是展示事务最后执行的语句（TRANSACTION 块末尾的 mysql thread id 对应的 QUERY），但常有陷阱：
- 如果事务里有多条语句，
QUERY只显示最后一条，而死锁可能由前面某条SELECT ... FOR UPDATE或UPDATE引起 - 如果用了预编译语句（如 JDBC 的 PreparedStatement），
QUERY显示的是带问号的模板，看不到实际参数，需结合应用日志比对 -
LOCK WAIT行里出现的index <code>xxx是线索：说明锁落在哪个索引上，反向推导 SQL 是否命中了预期索引 - 若看到
gap lock或insert intention lock，基本可断定是 RR 隔离级别下因间隙锁重叠导致，常见于INSERT ... ON DUPLICATE KEY UPDATE或范围条件更新
实操建议：
- 立即复制整个
SHOW ENGINE INNODB STATUS输出，用文本编辑器搜索<strong><em> (1)</em></strong>和(2)定位两个事务块 - 对每个事务，记下
mysql thread id，再查information_schema.PROCESSLIST确认该连接的用户、db、command、time，辅助判断业务场景 - 若发现
HELD LOCKS数量异常高（比如 > 50），大概率是没走索引导致全表扫描锁行，不是逻辑问题，是索引缺失
innodb_print_all_deadlocks=ON 是必须开的长期配置
SHOW ENGINE INNODB STATUS 只留最后一次死锁，线上偶发死锁根本抓不到。启用 innodb_print_all_deadlocks 后，每次死锁都会追加写入 MySQL 错误日志（error log），内容和 SHOW 输出一致，但永久留存、可追溯、可监控告警。
- 开启方式只需一条命令：
SET GLOBAL innodb_print_all_deadlocks = ON - 该配置无性能损耗，官方明确说明“only writes to error log, no impact on throughput”
- 日志路径由
log_error参数指定，确认该文件可读、有足够磁盘空间、有 logrotate 机制 - 别依赖
innodb_status_output_locks：它每 15 秒 dump 全量锁状态，日志爆炸且难过滤，纯属调试用，非死锁排查主路径
注意：该配置仅影响新发生的死锁，已发生的不会补录。上线后至少观察 24 小时，确认日志中是否持续出现死锁条目。
拿到冲突 SQL 后，怎么快速验证是不是真因顺序不一致导致
定位到两条 SQL 后，不能直接改代码——得先复现并确认根因。最有效的方式是构造最小可复现事务序列：
- 在测试库开启两个客户端，分别执行两个事务的 SQL，严格按日志里显示的加锁顺序执行（比如事务1先
SELECT ... FOR UPDATE再UPDATE，事务2反过来） - 若能稳定复现
ERROR 1213，就坐实了“加锁顺序不一致”问题 - 此时不要急着加锁超时或降隔离级别，先检查：两条 SQL 是否都走了相同索引？WHERE 条件是否都命中了索引最左前缀？有没有隐式类型转换导致索引失效？
常见翻车点：
- 一个事务用
WHERE user_id = 123（int），另一个用WHERE user_id = '123'（string），触发隐式转换，索引失效，锁扩大 - 一个事务更新主键
WHERE id = ?，另一个更新二级索引WHERE status = ? AND created_at > ?，锁的不是同一棵树，天然易冲突 - 批量更新语句未加
ORDER BY，InnoDB 扫描行物理顺序不确定，不同事务加锁顺序自然不一致
复现成功后，修复方向就很清晰：统一 WHERE 条件写法、补全缺失索引、给批量更新强制加 ORDER BY primary_key。这些改动比加重试逻辑更治本。
死锁日志里藏的不是答案，是线索。真正耗时间的从来不是“看到什么”，而是“看懂每一行背后的锁行为”。间隙锁怎么交叠、插入意向锁为何阻塞、S 锁为何升级失败——这些细节不抠清楚，光改 SQL 顺序只是暂时绕开，下次换两个表照样撞上。
