死锁是加锁顺序不一致的必然结果，非mysql bug；innodb会主动检测并回滚事务报“deadlock found”，根本原因是多个事务以不同顺序争抢同一组资源锁，间隙锁和next-key锁在rr级别下易引发隐蔽死锁。
死锁不是 MySQL 的 bug，而是加锁顺序不一致的必然结果
MySQL（InnoDB）本身会主动检测并回滚一个事务来打破死锁，报错信息一定是 Deadlock found when trying to get lock。这说明系统没卡死，只是你写的事务逻辑“自己绕进去了”。核心原因就一条：**两个及以上事务，以不同顺序申请同一组资源的锁**。比如事务 A 先锁 user_id=100，再锁 order_id=500；事务 B 反过来先锁 order_id=500，再锁 user_id=100 —— 这个交叉瞬间，InnoDB 就判定为死锁。
间隙锁（Gap Lock）和 Next-Key Lock 是 RR 隔离级别下最隐蔽的死锁推手
在默认的 REPEATABLE READ 隔离级别下，InnoDB 不只锁记录，还锁“间隙”。比如索引值是 10, 20, 30，执行 SELECT * FROM t WHERE id > 15 AND id ，实际会锁住 (10,20) 和 (20,30) 两个间隙，甚至可能延伸到 (20,30) 中的插入点。这时如果另一个事务想插入 <code>id=22，就会被阻塞；而它又恰好持有事务 A 需要的某条记录的 X 锁，死锁就成立了。尤其注意：WHERE 条件没走索引、用了范围查询（BETWEEN、>、LIKE 'abc%'）、或联合索引只用左前缀时，间隙锁范围极易失控。
查死锁不能只看错误日志，必须立刻执行 SHOW ENGINE INNODB STATUS
这个命令返回的 LATEST DETECTED DEADLOCK 区块，才是破案现场。重点关注三块：
– 每个事务正在执行的 SQL 语句
– 各自持有的锁类型（X、S、GAP、NEXT-KEY）和锁定的具体索引/记录
– 哪个事务被选为 victim（被回滚的那个）
常见误区是只看应用层报错，却忽略这里暴露的锁粒度和索引使用问题。例如发现某条 UPDATE 实际锁了 200 行，但 EXPLAIN 显示没走索引，那根因就是缺失索引，不是并发高。
避免死锁不是靠调参数，而是控制事务内锁的“确定性”
以下做法直接降低死锁概率：
– 所有涉及多行更新的业务，强制按主键/唯一索引升序排列后再批量处理（比如先 ORDER BY id ASC 再 FOR UPDATE）
– 删除或更新前，用 SELECT ... FOR UPDATE 一次性锁住所有目标行，而不是循环单条加锁
– 高并发写场景下，把 REPEATABLE READ 降为 READ COMMITTED（牺牲一致性换稳定性），此时间隙锁失效，死锁大幅减少
– 禁止在事务里做 HTTP 调用、文件读写、sleep 等耗时操作——长事务 = 锁持有时间拉长 = 死锁温床
最常被忽略的一点：ORM 自动生成 SQL 的 where 条件顺序不可控（如 GORM 的 struct 字段顺序影响条件拼接），这种“隐形不一致”比手写 SQL 更难排查。
