死锁不是 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 更难排查。
