根本原因是InnoDB在RR级别下为防幻读和保证唯一性，必须对冲突唯一索引的间隙加Next-Key Lock；该锁是冲突检测强制环节，无法绕过，且多唯一键、空表等场景会加剧死锁风险。
INSERT ON DUPLICATE KEY UPDATE 为什么在 RR 隔离级别下必加 Next-Key Lock
根本原因不是语句写法问题，而是 InnoDB 在 REPEATABLE READ 隔离级别下，为防止幻读和保证唯一性约束，**必须对冲突唯一索引值所在间隙加 Next-Key Lock（记录锁 + 间隙锁）**。这个动作是冲突检测的强制环节，无法跳过或绕开。
比如表有唯一索引 uk_order_sn，当前已有 'SN_1001' 和 'SN_1005'，此时并发插入 'SN_1003'：所有事务都会尝试在 (SN_1001, SN_1005) 这个间隙申请 S 类 Next-Key Lock —— 它们彼此兼容，但一旦其中某个事务回滚，剩余事务被唤醒后会转而竞争同一行的 X 锁，而此时它们各自已持有一个重叠的 S 类间隙锁，InnoDB 就判定为循环等待。
- 空表时更危险：间隙范围是
(−∞, +∞)，所有并发 INSERT 都挤在同一个超大间隙里抢锁 - 锁类型混合出现：
lock_mode S locks gap before rec和lock_mode X locks gap before rec insert intention waiting同时存在，是典型死锁前兆 - 即使只用一个唯一索引，只要并发量上来、事务执行节奏稍有错位，就可能触发
多个唯一索引会让死锁概率指数级上升
当表上有多个唯一键（如主键 + uk_phone + uk_email），INSERT ... ON DUPLICATE KEY UPDATE 的行为变得不确定：InnoDB 检查唯一键的顺序取决于索引创建时间，而非定义顺序或字母序。
不同事务可能因检查路径不同，最终锁定不同索引上的不同间隙。比如事务 A 先检查 uk_phone 发现冲突并加锁，事务 B 却先检查 uk_email 加了另一组间隙锁 —— 两者锁范围不重合但又互相阻塞后续操作，极易形成跨索引的循环等待链。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 主从复制若用基于语句的 binlog（SBR），主库和从库索引创建时间不一致，会导致同一语句在两边加锁范围不同
- 官方明确标记该语句为 unsafe：MySQL Bug #58637 指出 “
INSERT ... ON DUPLICATE KEY UPDATEagainst a table having more than one unique or primary key is also marked as unsafe” - SHOW ENGINE INNODB STATUS 中常看到多条
lock struct(s)分别落在不同索引上
死锁日志里最该盯住的三类线索
遇到 Deadlock found when trying to get lock; try restarting transaction（错误码 1213），不要只看报错本身。关键信息全藏在 SHOW ENGINE INNODB STATUS 的 LATEST DETECTED DEADLOCK 区域：
- 找
lock_mode X locks gap before rec或lock_mode S locks gap before rec—— 确认是不是间隙锁冲突 - 看
index xxx of table yyy—— 明确是哪个唯一索引引发的锁争抢 - 比对两个事务的 SQL 执行顺序和锁等待关系（
WAITING FOR THIS LOCK TO BE GRANTEDvsHOLDS THE LOCK(S)）—— 判断是否构成 A→B→A 循环
注意：日志中若出现 insert intention waiting，说明事务已在间隙内排队，但被前面的 S 锁卡住，这是死锁高发前的明确信号。
真正能落地的解法不是重试，而是控制锁粒度
业务层加重试只能掩盖问题，不能消除死锁根源。有效手段必须直击间隙锁生成机制：
- 把隔离级别降到
READ COMMITTED：执行SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，InnoDB 会禁用间隙锁，只保留记录锁；代价是可能产生幻读，但多数幂等插入场景可接受 - 确保唯一约束字段走的是 **确定性唯一索引**：避免多唯一键共存；若必须多唯一键，至少保证主库/从库索引创建顺序一致
- 用
INSERT IGNORE替代（当业务允许“失败静默”时）：它不走 UPDATE 路径，不触发 S 锁 → X 锁升级，只加插入意向锁，冲突时直接丢弃 - 预占位 + 应用层幂等：对关键业务字段（如订单号）提前用
SELECT ... FOR UPDATE加行锁（需精确命中唯一索引），再做 INSERT，但务必确认 WHERE 条件能走索引，否则会升级成表锁
最容易被忽略的一点：空表或低数据量表的并发插入，死锁不是偶发，而是必然。此时哪怕只有一条唯一索引，RR 级别下所有事务都在 (−∞, +∞) 里抢同一个 Insert Intention Lock，InnoDB 的锁排队机制天然就会构造出循环等待链。
