根本原因是InnoDB在RR隔离级别下为唯一性检查加Next-Key Lock（Gap Lock+Record Lock），而非仅Record Lock，以防止间隙内插入破坏唯一性的数据；当多事务并发检查同一间隙时，因插入意向锁与Gap Lock互斥而形成循环等待。
并发执行 INSERT ... ON DUPLICATE KEY UPDATE 会死锁，根本原因不是语句本身写错了，而是 InnoDB 在 RR 隔离级别下为保证唯一性检查而加的锁顺序不一致 + 间隙锁（Gap Lock）和插入意向锁（Insert Intention Lock）发生循环等待。
为什么唯一键冲突时会加 Next-Key Lock 而不是 Record Lock
当插入值触发唯一索引冲突（比如 uk_column = 5 已存在），InnoDB 不只是给那条冲突行加 S 锁，还会在该值所在的**索引间隙**上加 Next-Key Lock（即 Gap Lock + Record Lock）。这是为了防止其他事务在间隙里插入“看似不冲突但实际会破坏唯一性”的数据（例如插入 uk_column = 4.5，虽然当前没这列，但若索引是整型，它可能落在 (3,5) 间隙中）。
常见误解是：“只更新已有行，所以只锁那一行”。错——ON DUPLICATE KEY 的执行分两步：先尝试插入（触发唯一性检查 → 加间隙锁），发现冲突后再回滚插入动作、转而执行 UPDATE（此时再加 X 锁）。中间这个“检查-回滚-重试”过程让锁范围扩大了。
- 空表或新范围插入时，InnoDB 可能对 (−∞, +∞) 或 (prev, next) 整个间隙加锁
- 多个唯一索引（如主键 +
UNIQUE(a)+UNIQUE(b)）会让锁检查顺序依赖索引创建顺序，不同事务可能按不同顺序申请锁 - MySQL 5.7.25+ 对单唯一键场景做了优化，但多唯一键或组合唯一索引仍高危
死锁典型时序：两个事务互相卡在间隙上
假设表 t 有 PRIMARY KEY(id) 和 UNIQUE KEY uk_a(a)，当前数据：a=1、a=5、a=10。
事务 T1 执行：INSERT INTO t (id,a,b) VALUES (100,3,100) ON DUPLICATE KEY UPDATE b=100 → 检查 a=3，落在间隙 (1,5)，加 Next-Key Lock on (1,5)
事务 T2 执行：INSERT INTO t (id,a,b) VALUES (200,4,200) ON DUPLICATE KEY UPDATE b=200 → 同样落在 (1,5)，也尝试加 Next-Key Lock on (1,5)
此时 T1 持有 (1,5) 上的锁并等待插入意向锁（因要真正写入 id=100），T2 同样持有 (1,5) 锁并等待自己的插入意向锁 —— 但 InnoDB 规定：**插入意向锁与 Gap Lock/Next-Key Lock 是互斥的**。于是双方僵持，触发死锁检测并回滚其一。
- 关键点：不是“更新同一行”才死锁，而是“检查同一间隙”就可能卡住
-
SHOW ENGINE INNODB STATUS中看到lock_mode X waiting+gap或next-key字样，基本可确认 - 即使表里没有 a=3 或 a=4 的数据，只要它们落在同一个间隙，就共享锁资源竞争
为什么批量 INSERT ON DUPLICATE KEY 更容易出问题
批量语句如 INSERT INTO t VALUES (1,2),(2,3),(3,4) ON DUPLICATE KEY UPDATE ... 不是原子地“逐行判断”，而是对每行独立走一遍“检查→锁间隙→冲突则更新”流程。这意味着：
- 三行数据若都落在同一间隙（如 a 值全为 3、4、4.5），会三次申请同一间隙锁，放大冲突概率
- 各事务处理行的顺序可能不同（尤其用 ORM 自动生成 SQL 时），导致锁申请顺序不一致，打破“顺序加锁防死锁”原则
- 批量操作持续时间更长，锁持有窗口拉宽，提高并发撞车几率
- 某些客户端驱动（如旧版 MySQL Connector/J）在批量执行时还可能拆成多个隐式事务，进一步扰乱锁行为
最常被忽略的实战细节
很多团队改用 REPLACE INTO 或先 SELECT ... FOR UPDATE 再 INSERT/UPDATE，结果发现死锁照旧 —— 因为这些方案同样会触碰间隙锁。真正可控的缓解点其实很窄：
- 确保表**只有一个唯一约束**（主键 or 单一 UNIQUE 索引），避免多唯一键带来的非确定性锁序
- 把
INSERT ... ON DUPLICATE KEY UPDATE拆成**单行语句执行**，配合应用层重试（死锁异常捕获后重放），比强行批量更稳 - 如果业务允许，将隔离级别降为
READ-COMMITTED：该级别下 InnoDB 不使用 Gap Lock（仅 Record Lock），可彻底规避间隙类死锁，但需确认业务能接受幻读 - 不要依赖“表数据量小就不会死锁”——空表第一次插入时，InnoDB 会对 (−∞, +∞) 加最大间隙锁，反而最容易撞上
