insert ignore 并发插入相同唯一键时会因插入意向锁与gap锁相互等待而死锁，而非跳过冲突；replace into 和 insert ... on duplicate key update 同样存在加锁风险，根治需统一访问顺序与精准索引。
INSERT IGNORE 并发插入相同唯一键时，锁等待会形成循环
它不是“跳过”冲突，而是先加插入意向锁（INSERT intention lock），再尝试获取该唯一键对应记录的X锁或gap锁。两个事务同时执行 INSERT IGNORE 相同值，可能互等：A在等B释放gap锁，B在等A释放插入意向锁——这就是死锁回路的起点。
典型现象是日志里没报 Duplicate entry，却抛出 Deadlock found when trying to get lock。这说明语句根本没走到“判断是否重复”的逻辑层，卡在了加锁阶段。
- 联合唯一索引（如
(a, b)）中含NULL时，因NULL不参与唯一性比较，但 gap 锁范围仍重叠，极易触发 - 多个唯一索引（如
UNIQUE(email)和UNIQUE(phone)）并发写入时，InnoDB 内部加锁顺序不一致，也会导致死锁 -
REPLACE INTO风险更高：它实际执行“删 + 插”，需先持原行X锁，再申请新行意向锁，双锁+双索引场景下死锁概率陡增
SELECT FOR UPDATE 查不到记录时，gap锁范围失控
很多人用 SELECT ... FOR UPDATE 先查再插，以为能避免冲突。但如果查不到记录，InnoDB 会在唯一索引的“间隙”上加 gap lock —— 这个间隙可能覆盖后续多个合法插入点。当多个事务并发查同一间隙（比如都查 WHERE order_no = 'ORD-123' 但该单号还不存在），它们各自持有的 gap lock 就会互相阻塞。
更糟的是，如果 WHERE 条件没命中唯一索引（例如 user_id 字段无索引），SELECT ... FOR UPDATE 会退化为全表扫描并逐行加锁，直接变成表级竞争。
- 务必用
EXPLAIN验证type是const或eq_ref，而非ALL或index - 避免对唯一索引字段使用函数包裹（如
WHERE UPPER(email) = ?），否则索引失效，gap lock 扩张 - RR 隔离级别下，范围查询（如
WHERE status IN (1,2)）会触发 Next-Key Lock，锁住整个区间，不是单点
INSERT ON DUPLICATE KEY UPDATE 的查找阶段也加锁
这个语句常被误认为“原子且安全”，但它内部仍是三步：定位 → 加锁 → 插入或更新。问题出在第一步——如果 ON DUPLICATE KEY 依赖的字段（如 order_no）没有唯一索引，InnoDB 就无法快速定位，只能扫描并尝试锁住“可能插入的位置”附近的间隙。
结果就是：即使最终走的是 UPDATE 分支，查找过程已把其他事务堵在门外；而并发插入不同值但落在同一 gap 区间时，就互相等待。
- 必须确保
ON DUPLICATE KEY所依据的列，有且仅有一个**生效的唯一索引**（主键或UNIQUE索引） - 不要混用
INSERT IGNORE和INSERT ... ON DUPLICATE KEY UPDATE在同一张表的热点路径上，加锁行为不一致 - 更新子句里至少显式设置一个字段（哪怕
updated_at = updated_at），否则 InnoDB 可能跳过部分锁优化
真正有效的解法不在SQL语法，而在访问顺序与索引精度
换 REPLACE、加重试、调隔离级别，都是绕开问题。根治要从两处下手：一是让所有事务按同一顺序触达数据，二是让每条语句锁得准、锁得少。
- 对高频写入的唯一键（如手机号、订单号），应用层做幂等预判：
SELECT id FROM t WHERE key = ? LOCK IN SHARE MODE，查到则走更新，查不到再INSERT，全程只锁一行 - 多表事务必须固化访问顺序，比如所有涉及
accounts和orders的操作，统一先accounts后orders - 删除冗余唯一索引——如果已有联合索引
(status, user_id)覆盖常用查询，再单独建UNIQUE(user_id)反而扩大 gap lock 范围
最易被忽略的一点：死锁日志里出现 gap before rec insert intention waiting 时，别急着改代码，先检查那个字段是不是真有唯一索引，以及索引定义是否被隐式转换或函数包裹悄悄绕过了。
