必须开启innodb_print_all_deadlocks=on，否则仅靠show engine innodb status只能捕获最后一次死锁，无法反映生产环境高频批量死锁的真实分布；需在my.cnf中配置并重启，日志输出至log_error指定文件，结合holds/waiting锁信息与sql语句定位事务冲突根源。

必须立刻开 innodb_print_all_deadlocks = ON，否则你看到的永远只是冰山一角。

为什么 SHOW ENGINE INNODB STATUS 只能帮你解决 10% 的问题

它只保留最近一次死锁，而生产环境里高频死锁往往批量发生——你查到的可能是凌晨三点那个孤立 case，不是白天每分钟都在撞的主路径。更麻烦的是，SHOW ENGINE INNODB STATUS 不记录时间戳、不带上下文堆栈、不关联应用线程 ID，纯靠人工对 SQL 猜业务逻辑。

• 临时生效：SET GLOBAL innodb_print_all_deadlocks = ON;
• 持久化配置：在 my.cnf 的 [mysqld] 段加 innodb_print_all_deadlocks = 1，并确认 log_error 路径 MySQL 进程有写权限（否则静默失效）
• 日志量可控：单次死锁日志约 2–5 KB，远小于慢查询日志；但若每秒超 10 次，说明代码层已失控，别先想着关它

从死锁日志里快速定位冲突点的三步法

拿到 error log 里的 *** (1) TRANSACTION 和 *** (2) TRANSACTION 块后，不要读全文，盯这三项：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 看 trx query —— 找出最后卡住的那句 SQL，它未必是第一句，但一定是触发等待的临界点
• 比对 HOLDS THE LOCK(S) 和 WAITING FOR THIS LOCK TO BE GRANTED —— 如果都落在同一个索引（比如 idx_user_id），且 lock_mode 是 X locks rec but not gap，基本就是同一行被两个事务先后 UPDATE
• 查 lock_mode 类型 —— 出现 gap 或 next-key，说明涉及范围查询或非唯一索引，得立刻检查 WHERE 条件是否走了索引、有没有隐式类型转换

真正降低死锁率的三个硬动作

日志只能告诉你“谁锁了谁”，不能自动修复。根因 80% 以上来自应用层行为失控：

• 强制统一 DML 顺序：比如所有涉及 orders 和 inventory 的事务，无论哪个接口入口，都必须先 UPDATE orders 再 UPDATE inventory（反过来也行，但必须全局一致）
• 消灭隐式锁扩大：检查所有报死锁的 SQL 是否走了预期索引，EXPLAIN 看 type 是否为 const/ref；WHERE 条件字段没索引？立刻加
• 拆长事务：事务里调用外部 HTTP、做复杂计算、sleep 或等 MQ 回执？这些必须挪到事务外——锁持有时间越长，撞上其他事务的概率呈指数上升

死锁不是数据库故障，是并发逻辑暴露出来的信号。最危险的不是第一次死锁，而是你 fix 掉一条 SQL 后，同类模式在另一条路径里继续静默发生——所以一定要从日志里反推调用链，而不是只修表层 SQL。