InnoDB主动检测并回滚代价最小事务以解除死锁，非故障而是正常策略；需通过索引优化、访问顺序统一、小事务拆分及应用层重试来降低死锁概率。
死锁不是InnoDB“没处理好”，而是它主动检测并牺牲一个事务
InnoDB 遇到死锁时不会卡住或无限等待，而是通过内置的死锁检测器（wait-for graph）在几毫秒内识别出循环等待，并选择一个代价最小的事务回滚——这个被回滚的事务会收到 Deadlock found when trying to get lock; try restarting transaction 错误。关键点在于：这不是故障，是正常策略。常见误解是“加了索引就不会死锁”，其实只要两个事务以不同顺序访问相同资源（哪怕都是走索引），就可能触发死锁。
典型死锁场景：UPDATE 顺序不一致 + 无覆盖索引
最常复现的死锁发生在多条件 UPDATE 或范围操作中，尤其当 WHERE 条件未命中唯一索引、或扫描路径不可预测时。例如：
-- 事务A UPDATE accounts SET balance = balance - 100 WHERE user_id = 1001 AND status = 'active'; -- 事务B UPDATE accounts SET balance = balance + 100 WHERE user_id = 1002 AND status = 'active';
如果 user_id 是主键但 status 没有索引，InnoDB 可能对整个二级索引 status 进行范围扫描，锁住多个间隙（gap lock），而两个事务又交叉更新不同 user_id 行，就容易形成锁等待环。
- 务必为 WHERE 中高频出现的非主键字段建立联合索引，例如
(status, user_id)，让查询能走索引且扫描范围确定 - 避免在事务中执行不确定扫描范围的操作，如
SELECT ... FOR UPDATE带模糊条件（LIKE '%abc'） - UPDATE 语句尽量只更新必要字段，减少锁升级概率（例如不要用
SET *）
如何快速定位死锁原因：看 SHOW ENGINE INNODB STATUS
执行该命令后，输出末尾的 LATEST DETECTED DEADLOCK 区域才是关键。它包含：
- 两个事务各自持有的锁（
HELD LOCKS）和正在等待的锁（WAITING FOR THIS LOCK TO BE GRANTED） - 每个事务最后执行的 SQL（注意：不一定是导致死锁的那条，但通常是最近的 DML）
- 锁类型（
record lock、gap lock、next-key lock）和锁定的具体索引名
重点比对两事务的 lock_mode 和 lock_trx_id，再结合表结构判断是否因索引缺失或访问顺序不一致导致。不要只看 SQL 文本，要看实际加锁的索引和记录位置。
死锁无法完全避免，但可大幅降低：重试 + 顺序约定 + 小事务
应用层必须处理 Deadlock found... 错误，简单重试 1–2 次通常就能成功。除此之外：
- 所有涉及多行更新的业务逻辑，强制按主键升序（或固定字段排序）处理，例如先
SELECT ... ORDER BY id FOR UPDATE再逐条更新 - 拆分大事务：一个事务里不要同时操作用户表、订单表、库存表；把跨表逻辑放到应用层协调
- 监控慢日志中频繁出现的
UPDATE ... WHERE ...语句，检查其EXPLAIN是否走了预期索引，有没有隐式类型转换导致索引失效
真正难调的死锁往往藏在看似简单的批量更新里——比如用 IN (1,5,3,9) 更新，InnoDB 实际加锁顺序可能按索引物理位置而非 IN 列表顺序，这时候显式 ORDER BY 就很关键。
