SQL死锁是多个事务以不同顺序争夺同一组资源导致的循环等待现象，需满足互斥、请求保持、不可剥夺和循环等待四条件；InnoDB自动回滚改动少的事务，常见于交叉更新、间隙锁冲突及查后删/插等场景。
SQL死锁不是随机发生的异常，而是特定并发操作与加锁顺序共同作用的结果。核心在于“多个事务以不同顺序争夺同一组资源”，只要满足互斥、请求保持、不可剥夺和循环等待四个条件，死锁就可能触发。MySQL InnoDB 会自动检测并回滚一个事务（通常是改动行数更少的），但频繁死锁会影响业务稳定性。
常见死锁场景：交叉更新（AB-BA）
这是最典型、最容易复现的死锁模式。
- 事务A先更新id=1，再尝试更新id=2；
- 事务B先更新id=2，再尝试更新id=1；
- 当A持有id=1的排他锁、B持有id=2的排他锁时，双方都在等对方释放锁——循环等待形成。
例如：
T1: BEGIN; UPDATE users SET balance=100 WHERE id=1;T2: BEGIN; UPDATE users SET balance=200 WHERE id=2;
T1: UPDATE users SET balance=150 WHERE id=2; → 等待T2释放id=2锁
T2: UPDATE users SET balance=250 WHERE id=1; → 等待T1释放id=1锁 → 死锁触发
容易被忽略的死锁：间隙锁 + 唯一索引冲突
在RR隔离级别下，INSERT … ON DUPLICATE KEY UPDATE 或唯一键重复插入，会同时申请间隙锁（gap lock）和插入意向锁（insert intention lock），而这两类锁互斥。
- 事务A执行 INSERT INTO t (num1) VALUES (5) ON DUPLICATE KEY UPDATE …，发现num1=5已存在，于是加next-key lock（含gap+record）；
- 事务B同样执行相同语句，也在同一间隙上申请插入意向锁；
- 因间隙锁阻塞插入意向锁，且双方都未提交，最终形成死锁。
这种死锁不涉及显式UPDATE，却在批量导入、幂等写入等场景高频出现。
归档/迁移类操作引发的隐性死锁
业务中常见的“查后删”“查后插”逻辑，在高并发下极易出问题。
- 事务A：BEGIN; INSERT INTO history SELECT * FROM main WHERE id=1; DELETE FROM main WHERE id=1;
- 事务B：BEGIN; INSERT INTO history SELECT * FROM main WHERE id=1;
- A在DELETE前已对main.id=1加了S锁（读），又试图升级为X锁；B也申请S锁，但A的升级请求和B的S锁请求在锁队列中形成依赖闭环。
本质是“共享锁升级冲突”，在InnoDB中表现为S→X升级被阻塞，而其他事务又在等该S锁——死锁判定成立。
如何快速定位死锁现场
别靠猜，用系统自带工具看真实链路：
- 执行 SHOW ENGINE INNODB STATUS\G，重点关注“LATEST DETECTED DEADLOCK”段，它会明确写出哪两个事务、各自持有什么锁、等待什么锁；
- 开启全局记录：SET GLOBAL innodb_print_all_deadlocks = ON，所有死锁都会写入错误日志，便于事后批量分析；
- 查实时状态：SELECT * FROM information_schema.INNODB_TRX 看活跃事务，INNODB_LOCK_WAITS 看谁堵了谁。
基本上就这些。关键不在“怎么杀掉死锁”，而在“怎么让事务按统一顺序拿锁、尽量缩短事务生命周期、避免在RR下做不必要的范围扫描”。
