唯一索引下的并发插入为何死锁：Duplicate Key 背后被忽略的间隙锁与自增主键插入顺序

作者陈知远-112

MySQLInnoDB死锁唯一索引并发间隙锁

结论先行：在 InnoDB 里，往带唯一索引的表并发 INSERT，最常见的死锁根因不是「写写竞争」，而是 Duplicate Key 检查触发的 S 锁 + 间隙锁，叠加自增主键的插入顺序不一致，形成 AB-BA 环路。这个坑我踩了两次，第一次还因为「死锁是偶发的」被当成偶发 bug 放过了。

一、现象与背景：QPS 不到 200，应用却频繁 5xx

我们有一张 t_idempotent（幂等去重表），结构如下：

CREATE TABLE t_idempotent (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  biz_key VARCHAR(64) NOT NULL,
  created_at DATETIME NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY uk_biz_key (biz_key)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

业务逻辑：每个请求带一个 biz_key（比如 order:20240511:88321），先 INSERT，依赖 uk_biz_key 唯一约束做去重——插入成功说明是新请求，插入报 1062（Duplicate Key）说明重复，直接丢弃。

规模：单表约 800 万行，QPS 峰值 ~180，8 个应用节点。

问题：从 5 月开始，应用侧 ER_LOCK_DEADLOCK (1213) 错误从「每天个位数」涨到高峰期每分钟 30~50 次，P99 从 12ms 飙到 800ms+，超时重试进一步放大了错误。业务侧表现为偶发的「重复扣款告警」（因为重试时走了另一条路径）。

一开始我以为是「连接数不够」或「锁等待超时」，改了 innodb_lock_wait_timeout、加了连接池，没用——因为这不是 lock wait，是 deadlock。

二、根因分析：Duplicate Key 检查到底拿了什么锁

先讲机制。InnoDB 里 INSERT 一条带唯一索引的记录，实际做了两件锁的事：

在聚簇索引（主键）上插入新行：对自增主键，这一步拿的是主键上的插入意向锁 + 新行的 X 锁，不涉及间隙锁（因为自增是「追加到末尾」，且 innodb_autoinc_lock_mode 我们用的是 2，即 interleaved 模式，主键分配不持表级 AUTO-INC 锁）。
在唯一二级索引 uk_biz_key 上插入：这一步要先检查唯一性。检查方式是：对该 biz_key 的值，在二级索引 B+ 树上定位到「这个值应该插入的位置」，对相邻记录之间加 Next-Key Lock（记录锁 + 间隙锁的合体），确认没有重复。

关键点来了：即使这条记录最终不存在（是新插入），InnoDB 在 INSERT 时也会在唯一索引上对相关区间加 S 锁做唯一性检查（详见 MySQL 文档中 "Duplicate-key checks" 一节）。如果这个区间里已经有别的并发事务持锁，就会等待。

死锁的典型 AB-BA 场景（两个并发事务 T1、T2，插入相邻但不相同的 biz_key）：

T1: INSERT biz_key='a100'  → 在 uk_biz_key 上对 ['a099','a101'] 区间加 S 锁（间隙）
T2: INSERT biz_key='a101'  → 同样要对 ['a099','a101'] 区间加 S 锁 → 等待 T1
T1: 随后要写聚簇索引主键行，但 T2 已经先插入了主键 id 更小的行，
    T1 的自增主键分配或插入顺序与 T2 交错 → 需要 T2 持有的主键区间锁
→ 环路形成 → InnoDB 选中代价小的（通常是 T2）做牺牲，报 1213

为什么自增主键顺序会「不一致」？ 因为 innodb_autoinc_lock_mode=2 下，自增值是按 batch 预分配的，两个并发事务拿到的 id 区间可能与业务 biz_key 的字典序不一致。如果 T1 先拿到 id=1000、T2 拿到 id=1001，但 T1 的 biz_key 字典序反而更大，那么在「二级索引 S 锁」和「主键插入顺序」两个维度上，T1、T2 的锁获取顺序就相反了——这正是 AB-BA 死锁的教科书条件。

三、具体做法：三层改造，按成本从低到高

1. 应用层：把「INSERT 失败」当正常路径，重试要幂等（成本最低，先做）

// 伪代码：捕获 1062 和 1213，但二者语义完全不同，不要混
try {
    idempotentMapper.insert(bizKey);
} catch (DuplicateKeyException e) {
    // 1062：重复请求，直接丢弃，这是「成功」
    return;
} catch (DeadlockLoserDataAccessException e) {
    // 1213：真·死锁，需要重试，但重试前必须确认这条是不是已经插入了
    // 不能简单再 INSERT 一次——可能上一次其实已经成功了一半
    boolean exists = idempotentMapper.exists(bizKey);
    if (exists) return;
    retryWithBackoff(() -> idempotentMapper.insert(bizKey));
}

坑：很多团队把 1213 和 1062 都 catch 成「重复，丢弃」，这是错的——1213 的事务可能已经回滚了主键行，直接丢弃会导致该请求被永久漏处理。

2. 索引层：把唯一索引改成「业务键 + 时间戳」复合，降低间隙锁冲突（中等成本）

-- 原：UNIQUE KEY uk_biz_key (biz_key)
-- 改：把 created_at 放进唯一键，让相邻插入的区间更分散
ALTER TABLE t_idempotent
  ADD UNIQUE KEY uk_bizkey_ts (biz_key, created_at);

这样做的原理：业务键本身是稀疏的（order:20240511:88321 这种字符串，字典序相邻但业务上无关），加上时间戳后，即使两个 biz_key 字典序相邻，它们的 (biz_key, created_at) 组合也不同，间隙锁命中的区间更小，AB-BA 概率显著下降。

代价：唯一性语义变了——同一 biz_key 现在允许不同时间戳插入多次。如果业务上要求「同一 biz_key 全生命周期只允许一次」，这条路不能走，只能用方案 1 + 方案 3。

3. 架构层：把「靠 DB 唯一约束去重」改成「Redis SETNX 前置 + DB 兜底」（成本最高，收益最大）

请求 → Redis SETNX biz_key EX 86400 → 成功则放行，失败则丢弃
                                ↓ 放行
                          INSERT t_idempotent（DB 唯一约束兜底）

Redis SETNX 是 O(1) 的原子操作，根本不需要在 B+ 树上做唯一性检查，也就不会触发那把 S 间隙锁。DB 的唯一索引保留，作为 Redis 故障时的兜底（Redis 挂了，请求穿透到 DB，DB 唯一约束仍然能拦住重复）。

实测：改造后 1213 错误从「高峰期每分钟 30~50 次」降到一周 0 次，P99 从 800ms 回落到 14ms。

四、踩过的坑与反直觉之处

坑 1：innodb_autoinc_lock_mode 设成 1 反而更差。 一开始我以为是「自增锁模式」的问题，把 innodb_autoinc_lock_mode 从 2 改成 1（consecutive，持 AUTO-INC 表级锁）。结果死锁没减少，反而吞吐量掉了 22%——因为表级 AUTO-INC 锁让并发插入串行化了。真正的问题在二级索引的间隙锁，不在自增分配。

坑 2：EXPLAIN 对 INSERT 没用。 EXPLAIN INSERT ... 只告诉你「走哪个索引」，不会告诉你会加哪些锁、锁住哪个区间。要看锁，得开 innodb_print_all_deadlocks=ON，然后去 SHOW ENGINE INNODB STATUS 的 LATEST DETECTED DEADLOCK 段里读——那段输出会明确写出「T1 在 uk_biz_key 上等待 S 锁，T2 持有」，比任何 EXPLAIN 都有用。

坑 3：把 biz_key 从 VARCHAR 改成 INT 不会解决问题。 有人建议「把字符串键改成自增 INT 键，间隙锁就小了」——错。问题不是键的类型，是并发事务在二级索引上的锁获取顺序与主键插入顺序不一致。改成 INT 键，只要插入顺序还是交错的，AB-BA 照样成立。

坑 4：重试要带退避，不能裸重试。 第一次死锁后立刻重试，两个事务的锁请求窗口高度重叠，第二次死锁概率反而更高。必须加随机退避（50~200ms），让两个事务的锁获取窗口错开。

五、结论与可复用清单

结论：InnoDB 里「靠唯一索引做并发去重」是一个反模式——它在低并发下没问题，但 QPS 上 100 后，Duplicate Key 检查触发的 S 间隙锁 + 自增主键插入顺序不一致，会形成 AB-BA 死锁，且死锁是「结构性」的，不是「偶发」的，重试和调参都治标不治本。

可复用清单（按优先级）：

应用层：1062（重复）和 1213（死锁）必须分开处理，1213 重试前要 SELECT EXISTS 确认状态，重试带随机退避。
诊断：开 innodb_print_all_deadlocks=ON，死锁发生后第一时间读 SHOW ENGINE INNODB STATUS 的 LATEST DETECTED DEADLOCK，看锁类型和等待方，别靠 EXPLAIN 猜。
索引层：如果业务允许「同一键不同时间可重复」，把唯一索引改成 (biz_key, created_at) 复合键，缩小间隙锁区间。
架构层：高并发去重场景，用 Redis SETNX 前置 + DB 唯一约束兜底，把 B+ 树上的唯一性检查挪到 O(1) 的哈希操作上。
参数：innodb_autoinc_lock_mode 保持 2（interleaved），别为了「治死锁」改成 1——那是吞吐量的税，不是死锁的解药。

一句话：死锁的根因是「锁获取顺序不一致」，不是「锁太多」。把去重从 B+ 树上挪走，比调任何参数都有效。

赞 2 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。