唯一索引并发插入易死锁，因其必须磁盘读校验冲突、提前加插入意向锁和间隙锁，且INSERT IGNORE不跳过加锁；RR级别下next-key lock扩大锁范围，高并发时易形成循环等待。
唯一索引强制触发磁盘读，锁获取路径更长
普通索引写入时可走 Change Buffer 缓存更新，不查磁盘；而唯一索引必须把对应索引页读进内存做冲突校验，这一步会提前加锁（INSERT intention lock + gap lock），且锁持有时间更长。锁还没真正“插进去”，就已经在等间隙释放了。
常见错误现象：SHOW ENGINE INNODB STATUS 里看到大量 waiting for insert intention lock，但 SQL 表面只是 INSERT IGNORE 或 INSERT ... ON DUPLICATE KEY UPDATE。
- 并发越高，等待链越容易形成环状依赖
- 如果表数据稀疏、索引范围大，gap lock 覆盖区间更广，冲突概率指数上升
- 函数索引或前缀索引会让实际匹配行为偏离预期，进一步放大锁范围
INSERT IGNORE 不跳过加锁，只跳过报错
INSERT IGNORE 的“忽略”仅作用于语句执行后是否报 Duplicate entry 错误，**不是跳过锁申请**。它仍会按标准流程申请插入意向锁 → 尝试获取唯一键记录锁 → 冲突时退为共享锁（S lock）或等待 X lock 释放。
典型陷阱场景：
- 事务 A 插入
(1, NULL)，事务 B 插入(1, 2)：因NULL不参与唯一比较，两者都落在同一 gap 区间，互相阻塞 - 混合使用
INSERT IGNORE和REPLACE INTO：前者加 S lock 等待，后者先删后插，要先拿 X lock，锁顺序完全错开 - 联合唯一索引中部分字段为
NULL，InnoDB 对 gap 的判断逻辑与业务预期不一致
REPLACE INTO 锁范围更大，死锁风险翻倍
REPLACE INTO 实质是 DELETE + INSERT 两阶段操作（除非满足极苛刻的优化条件）。它不仅要对目标唯一键加 X lock 删除旧行，还要对新行位置加插入意向锁——这意味着同一事务要持两个不同位置的锁，且顺序固定。
高危组合：
- 二级唯一索引上执行
REPLACE INTO：除唯一索引外，还会对主键索引加锁，锁粒度从单行扩大到多行 - 并发 REPLACE 相同键值：事务 A 持有 R1 的 X lock 等 R2 插入意向锁，事务 B 持有 R2 的 X lock 等 R1 插入意向锁 → 直接闭环
- 搭配
ON DUPLICATE KEY UPDATE使用时，若更新字段涉及其他索引，可能意外触发额外锁
RR 隔离级别下 next-key lock 是死锁温床
MySQL 默认 REPEATABLE READ 隔离级别启用 next-key lock（record lock + gap lock），这是为防幻读设计的，但在唯一索引并发插入时反而成了死锁催化剂。因为 gap lock 不是“锁某条记录”，而是“锁住一段空隙”，多个事务同时瞄准同一段空隙，就极易形成循环等待。
关键细节：
- 即使唯一索引字段值完全不存在（如插入一个全新
email），也会在相邻索引值之间加 gap lock - 唯一索引的 gap lock 范围比普通索引更难预测：例如索引值为
[1,5,9]，插入3会锁(1,5)，但插入0或10会锁边界外延区间 - 死锁日志里常出现
S lock on next-key和X lock on record并存，说明一个事务在等 gap，另一个在等 record，互不相让
