根本原因在于InnoDB在REPEATABLE READ隔离级别下，执行INSERT ON DUPLICATE KEY UPDATE时必须对冲突唯一索引值所在间隙加Next-Key Lock，该锁是冲突检测的强制环节，非可选行为。
Insert On Duplicate Key Update 为什么会触发间隙锁
根本原因在于 MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE 在检测到唯一键冲突时，会先尝试插入，失败后转为更新——但这个“尝试插入”过程已经持有了插入意向锁（INSERT intention lock），并可能在唯一索引上加了**间隙锁（gap lock）** 或**临键锁（next-key lock）**，尤其当冲突发生在非精确匹配的范围时。
常见错误现象：Deadlock found when trying to get lock; try restarting transaction，且 SHOW ENGINE INNODB STATUS 中显示两个事务互相等待对方持有的 gap lock。
- 即使表只有主键或唯一索引，只要 WHERE 条件未命中现有记录（比如插入一个新值但落在已有索引值的间隙中），InnoDB 就会锁定该间隙防止幻读
- 多个并发事务同时执行
INSERT ... ON DUPLICATE KEY UPDATE插入相邻或重叠的键值（如自增 ID 接近、手机号前缀相同），极易因 gap lock 范围重叠而相互阻塞 - RR 隔离级别下 gap lock 默认启用；RC 级别可规避，但会丢失一致性语义（如重复插入不报错但也不更新）
为什么 REPLACE INTO 不一定比 ON DUPLICATE 更安全
REPLACE INTO 表面看是“删+插”，实际执行分三步：delete → insert → auto-increment 可能跳变。它同样需要先定位记录（加 S 锁），再加 X 锁删除，最后插入时又申请插入意向锁和新记录的 X 锁——这反而扩大了锁持有时间窗口。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 如果被替换的记录有外键引用或触发器，
REPLACE INTO会触发 delete + insert 两轮开销，锁竞争更明显 - 在唯一索引多于一个时，
REPLACE INTO可能因按不同索引路径查找而产生不一致的加锁顺序，加剧死锁概率 -
ON DUPLICATE KEY UPDATE至少只走一次索引查找，锁范围相对可控（前提是更新字段不涉及其他唯一索引列）
如何用 INSERT IGNORE + 显式 UPDATE 降低死锁风险
拆成两阶段：先用无锁冲突的 INSERT IGNORE 尝试插入，失败后再执行 UPDATE ... WHERE。虽然多一次 round-trip，但避免了单语句中“插入试探+更新”的混合锁行为。
-
INSERT IGNORE在冲突时不报错、不加 gap lock（仅对已存在记录加 S 锁），释放快 - 后续
UPDATE只对明确命中的主键/唯一键加记录锁（record lock），不扩展到间隙 - 必须确保
UPDATE的WHERE条件能精确命中索引（如用主键或唯一索引列），否则仍可能触发 gap lock - 注意应用层需处理“插入失败但更新也失败（比如记录被删）”的边界情况
真正关键的预防点：索引设计与业务写法
多数死锁不是语法问题，而是索引覆盖不足或写法放大锁粒度。比如用 INSERT ... ON DUPLICATE KEY UPDATE 更新一个非唯一字段，却只靠主键做冲突判断——这时 InnoDB 仍要扫描整个唯一索引范围来确认“没冲突”，锁住大片间隙。
- 确保
ON DUPLICATE KEY UPDATE的冲突判断列是**最窄的唯一索引**（比如优先用user_id而非(tenant_id, user_id)复合索引，除非业务强依赖租户隔离） - 避免在更新子句中修改唯一索引列本身（如
UPDATE name=..., email=VALUES(email)且email是唯一索引），会导致二次唯一性校验和额外锁 - 批量操作时，按主键升序排序后再执行，统一加锁顺序，从根源减少循环等待
死锁最常发生在你以为“只是更新一行”的时候——其实 InnoDB 已经为你锁了一整段索引间隙。看清 EXPLAIN 输出的 key_len 和 rows，比调优 SQL 更重要。
