MySQL 间隙锁导致无辜阻塞甚至死锁怎么办？

Question

仓乃文 · Accepted Answer

MySQL 在 RR（可重复读）隔离级别下，为了防止幻读会自动加间隙锁（Gap Lock）。间隙锁锁住的是索引记录之间的间隙，阻止其他事务在该间隙插入数据。这是 InnoDB 最隐蔽的锁机制，经常导致看似无关的事务互相阻塞甚至死锁。

问题复现：
```sql
-- 表中 id 有 1, 5, 10 三条记录
-- 事务 A
BEGIN;
SELECT * FROM t WHERE id = 3 FOR UPDATE;
-- 加了间隙锁 (1, 5)，阻止 id=2,3,4 的插入

-- 事务 B
BEGIN;
INSERT INTO t VALUES (4); -- 被事务 A 的间隙锁阻塞！
-- 事务 B 等待...

-- 更诡异的情况：两个事务都持有同一间隙的间隙锁
-- 间隙锁之间兼容，但插入意向锁与间隙锁互斥
-- 事务 A 持有 (1,5) 间隙锁，事务 B 也持有 (1,5) 间隙锁
-- 事务 A 要插入 id=4 → 等待 B 的间隙锁
-- 事务 B 要插入 id=3 → 等待 A 的间隙锁 → 死锁！
```

修复方案：
```sql
-- 方案 1：改用 RC 隔离级别（推荐，互联网业务首选）
SET GLOBAL transaction_isolation = "READ-COMMITTED";
-- RC 级别下间隙锁完全关闭，只有记录锁
-- 代价：可能出现幻读，但大多数业务可接受

-- 方案 2：缩小 FOR UPDATE 范围
-- 避免 SELECT ... FOR UPDATE 条件范围过大
-- 精确查询：WHERE id = 5 而非 WHERE id > 3

-- 方案 3：插入前先查询确认，减少间隙锁冲突
-- 方案 4：应用层加分布式锁替代数据库行锁
```

补充说明：
- 间隙锁只在 RR 级别生效，RC 级别完全不存在
- 临键锁（Next-Key Lock）= 记录锁 + 间隙锁，是 RR 下默认的行锁算法
- 唯一索引 + 精确匹配时，临键锁退化为记录锁，不会加间隙锁
- 规则：如果业务不需要严格防幻读，优先用 RC 隔离级别