MySQL死锁本质是多个事务因加锁顺序不一致陷入循环等待，需同时满足互斥、请求并保持、不可剥夺、循环等待四条件；常见于加锁顺序不一、间隙锁冲突、索引失效及主键与二级索引混用等场景。
MySQL死锁本质是多个事务因加锁顺序不一致，陷入互相等待的循环依赖状态。InnoDB 会自动检测并回滚其中一个事务（报错 ERROR 1213: Deadlock found when trying to get lock），但理解成因才能真正规避。
核心触发条件：四个必要条件同时满足
死锁不是偶然现象，它必须同时具备以下四点：
- 互斥条件：锁资源一次只能被一个事务持有（如 X 锁不允许多个事务同时写同一行）
- 请求并保持：事务已持有一把锁，又去申请另一把锁（例如已锁住 user_id=100，再试图锁 user_id=200）
- 不可剥夺：事务持有的锁不能被强行回收，只能自己释放（COMMIT 或 ROLLBACK 后才释放）
- 循环等待：形成闭环依赖，比如事务 A 等 B 的锁，B 又等 A 的锁
常见具体场景
这些业务操作模式最容易踩坑：
- 加锁顺序不一致：事务 A 先 update id=5 再 update id=3；事务 B 反过来先 id=3 后 id=5 —— 最典型死锁来源
- 范围查询引发间隙锁冲突：where age between 20 and 30 触发 gap lock，不同事务扫描重叠区间时可能锁住相同间隙
- 索引失效导致锁升级：本该走索引却全表扫描，把行锁扩大为大量行锁甚至隐式锁升级，增加碰撞概率
- 混合使用主键与二级索引：事务 A 用 name=xxx（二级索引）更新，事务 B 直接用主键 id 更新同一行 —— 两者加锁路径不同（先二级索引再聚簇索引 vs 直接聚簇索引），易形成交叉等待
容易被忽略的技术细节
很多死锁看似随机，其实有底层机制可循：
- InnoDB 的 next-key lock = 行锁 + 前隙锁，在 RR 隔离级别下默认启用，是范围查询死锁的主因
- 唯一索引上的等值查询（如 where id=100）只加记录锁（record lock），不加间隙锁；但非唯一索引或范围条件就会锁住间隙
- SELECT ... FOR UPDATE / LOCK IN SHARE MODE 的执行顺序直接影响加锁顺序，尤其搭配 IN 子句时 —— MySQL 会对 in 列表自动排序后加锁（如 in (5,1,3) 实际按 1→3→5 加锁），这是可控的突破口
- 长事务持有锁时间越长，与其他事务发生竞争的窗口越大，即使逻辑简单也容易卷入死锁
如何快速定位死锁根源
别只看报错，要抓关键证据：
- 执行 SHOW ENGINE INNODB STATUS\G，重点关注 LATEST DETECTED DEADLOCK 区块，里面明确写出哪两个事务、各自持有哪些锁、正在等待什么锁
- 检查事务中 SQL 的执行顺序、WHERE 条件是否走索引、是否含范围查询或 OR 条件
- 确认应用层是否对同一批数据做了无序的 for update 操作（如随机分配场景中借款人 ID 未排序）
