死锁不是必须修复的错误，而是innodb主动检测并终止低优先级事务的结果；真正要做的是降低发生频率——核心手段是调低隔离级别（如改为read committed）并补全缺失索引。
直接结论：死锁不是必须“修复”的错误，而是 InnoDB 主动检测并终止低优先级事务的结果；真正要做的，是降低其发生频率——核心手段就是调低隔离级别（如从 REPEATABLE READ 改为 READ COMMITTED） + 补全缺失的索引。
为什么 REPEATABLE READ 更容易触发死锁
InnoDB 在 REPEATABLE READ 下默认启用间隙锁（Gap Lock）和临键锁（Next-Key Lock），哪怕你只更新一行，也可能锁住一个值范围。比如执行 UPDATE orders SET status = 'paid' WHERE user_id = 123 AND created_at > '2026-05-01'，若 user_id 没有索引，InnoDB 可能对整个索引区间加锁；两个事务按不同顺序扫描同一区间，就极易形成 wait-for graph 环路。
而 READ COMMITTED 会禁用间隙锁（仅保留记录锁），锁粒度更小，冲突面大幅收窄。但要注意：
- 该级别下不会出现幻读保证，业务需确认是否可接受（例如分页查询重复或丢失数据）
- 某些依赖 MVCC 快照语义的逻辑（如多次读取同一行做条件判断）可能行为变化
-
binlog_format必须为ROW，否则主从不一致风险上升
哪些索引缺失最常导致死锁
死锁高频场景往往不是“没索引”，而是“索引没覆盖查询条件”。常见误判点：
-
WHERE条件含多个字段，但只建了单列索引（如status上有索引，但查询是WHERE status = 'pending' AND user_id = 456） - 使用了函数或表达式（如
WHERE DATE(created_at) = '2026-05-06'），导致索引失效，退化为全表扫描加锁 - 联合索引顺序错误（如建了
(a, b)，却查WHERE b = 1，无法走索引） -
ORDER BY或LIMIT配合WHERE时，优化器选错执行计划，实际扫描行数远超预期
验证方式：对报死锁的 SQL 执行 EXPLAIN，重点关注 type 是否为 ALL、key 是否为 NULL、rows 估算值是否异常高。
如何快速定位死锁源头 SQL
InnoDB 的死锁日志（SHOW ENGINE INNODB STATUS\G）里最关键的不是“谁被回滚”，而是 “LATEST DETECTED DEADLOCK” 下的两段事务堆栈：
- 找
TRANSACTION块里的mysql tables in use和locked行，确认涉及哪张表、哪些索引 - 看每条事务最后执行的
INSERT/UPDATE/DELETE语句，注意它是否带子查询、是否跨表、是否有OR条件（易导致索引失效） - 比对两个事务的加锁顺序：比如事务 A 先锁
users再锁orders，事务 B 反过来，这就是典型不一致访问顺序
不要只盯着报错时刻的 SQL——死锁是“历史操作+当前请求”共同导致的。一个长事务在开头 SELECT FOR UPDATE 锁了一堆行，后面其他事务再碰这些行，就容易卷入死锁。
innodb_lock_wait_timeout 不是解决死锁的开关
这个参数控制的是“锁等待超时”，不是“死锁检测超时”。死锁检测由 InnoDB 主动触发（wait-for graph 算法），毫秒级完成，跟该参数无关。把它设小（比如 1 秒）只会让普通锁等待更快失败，掩盖真实死锁频次，反而干扰排查。
真正该调的参数是：
-
innodb_deadlock_detect = ON（默认开启，别关） -
innodb_print_all_deadlocks = ON：把每次死锁都写进 error log，方便聚合分析 -
innodb_rollback_on_timeout = OFF（默认）：避免锁等待超时也触发回滚，混淆死锁信号
复杂点在于：死锁不是孤立事件。一次死锁背后，往往藏着慢查询、缺失索引、事务过长、应用层重试策略不合理等多个叠加问题。单独改一个隔离级别或加一个索引，可能压不住；得结合 slow_query_log 和应用链路追踪，看哪类事务总在“凑巧”撞上。
