MySQL间隙锁详解：解决幻读的「隐形守护者」

引言

你是否遇到过这种情况？
事务A查询某范围数据后，事务B插入了一条中间数据并提交，事务A再次查询时竟多出了一条「幻觉」记录——这就是数据库经典的幻读（Phantom Read）问题。而在MySQL InnoDB引擎中，间隙锁（Gap Lock）正是解决这一问题的核心利器。

今天，我们就来深入聊聊间隙锁的底层逻辑、使用场景、常见问题，以及如何避坑优化。

一、幻读：事务隔离的「隐形漏洞」

要理解间隙锁，得先搞清楚幻读是怎么产生的。

数据库的事务隔离级别中，可重复读（Repeatable Read，RR）是最常用的级别，它保证同一事务内多次读取的结果一致。但即便如此，RR也有「漏洞」：

举个栗子🌰：

• 事务A执行 SELECT * FROM user WHERE age BETWEEN 20 AND 30;，得到5条记录；
• 此时事务B插入一条 age=25 的新记录并提交；
• 事务A再次执行相同查询，发现结果多了1条——这就是幻读。

幻读的本质是：其他事务在当前事务的查询范围内插入了新数据，导致两次查询结果不一致。InnoDB为了解决这个问题，在RR隔离级别下引入了「间隙锁」。

二、间隙锁到底锁什么？

间隙锁（Gap Lock）的核心作用是：锁定索引记录之间的「间隙」，阻止其他事务在间隙内插入新数据。

1. 什么是「间隙」？

假设表的索引列（如id）有值 [1, 3, 5, 7]，那么索引之间的「间隙」就是这些值之间的区间：

• (-∞, 1)：小于1的区间
• (1, 3)：1和3之间的区间（可插入2）
• (3, 5)：3和5之间的区间（可插入4）
• (5, 7)：5和7之间的区间（可插入6）
• `(7, +∞)：大于7的区间

这些间隙是「潜在的插入位置」，间隙锁的作用就是暂时封锁这些区间，让其他事务无法在其中插入数据。

2. 间隙锁的「锁区」长什么样？

间隙锁锁定的是左开右开的区间（(gap_start, gap_end)）。例如，当锁定(3,5)间隙时，其他事务无法插入id=4（因为4在(3,5)内），但可以插入id=3或id=5（这两个是已有记录，由行锁控制）。

三、间隙锁什么时候生效？

间隙锁不是「无差别攻击」，它只在特定场景下触发。

1. 范围查询 + 加锁操作

当SQL使用范围条件（如>、<、BETWEEN）查询数据，并且显式加锁（如FOR UPDATE或LOCK IN SHARE MODE）时，InnoDB会自动添加间隙锁。

举个栗子🌰：

-- 事务A执行：锁定id在(10,20)之间的间隙（防止插入11~19）
SELECT * FROM user WHERE id > 10 AND id < 20 FOR UPDATE;

此时，InnoDB不仅会锁定查询到的行（如果有的话），还会锁定(10,20)这个间隙。

2. 临键锁（Next-Key Lock）的「隐藏技能」

InnoDB的默认行锁其实是临键锁（Next-Key Lock），它是「行记录锁」和「前向间隙锁」的组合。换句话说，当你用等值查询（如id=15）加锁时，临键锁会同时锁定该行记录，以及它前一个索引值到该行记录之间的间隙。

举个栗子🌰：
假设表中有id=10,20,30三条记录：

• 当事务A执行 SELECT * FROM user WHERE id=20 FOR UPDATE; 时，临键锁会锁定：
  • 行记录id=20（防止其他事务修改/删除它）；
  • 前向间隙(10,20)（防止插入11~19）。

四、间隙锁的关键特性：必须知道的3件事

1. 「索引依赖症」：没索引？锁表！

间隙锁的生效条件是查询必须使用索引。如果查询条件没用到索引（比如全表扫描），InnoDB会退化为表级间隙锁，直接锁定整个表的间隙，导致所有插入操作被阻塞！

危险操作示例❌：

-- name字段没有索引！InnoDB会锁定全表间隙！
SELECT * FROM user WHERE name = '张三' FOR UPDATE;

2. 「隔离级别限定」：读提交（RC）下无效

间隙锁仅在可重复读（RR）隔离级别下生效。如果你的隔离级别是读提交（READ COMMITTED），InnoDB会禁用间隙锁（通过参数innodb_locks_unsafe_for_binlog控制），此时可能出现幻读。

3. 「范围越大，锁越狠」：大范围查询的风险

如果你的查询范围很大（比如WHERE age > 0），间隙锁会锁定从最小索引到最大索引之间的所有间隙，导致后续所有插入操作（在该范围内）被阻塞，严重影响并发性能！

五、实战：间隙锁导致的典型问题与避坑指南

问题1：批量插入被阻塞

场景：
事务A执行 SELECT * FROM user WHERE age BETWEEN 20 AND 30 FOR UPDATE; 锁定了(20,30)间隙；
事务B尝试插入age=25的新记录，结果被阻塞，直到事务A提交。

避坑建议：
如果业务允许，尽量缩小查询范围（比如BETWEEN 25 AND 28），减少锁定的间隙；或者调整隔离级别为读提交（需评估幻读风险）。

问题2：未使用索引导致锁表

场景：
事务A执行 SELECT * FROM order WHERE user_name = '李四' FOR UPDATE;（user_name无索引）；
此时InnoDB会锁定全表间隙，所有插入order表的操作都被阻塞！

避坑建议：
为常用查询条件添加索引（如给user_name加索引）；如果无法加索引，考虑降低隔离级别或避免加锁查询。

问题3：长事务引发锁等待

场景：
事务A是一个长事务（执行了10分钟），期间一直持有某个间隙锁；
事务B尝试插入数据，被阻塞10分钟后超时报错。

避坑建议：
缩短事务执行时间（避免在事务中做耗时操作，如慢查询、网络请求）；及时提交或回滚不再需要的事务。

六、总结：间隙锁的正确打开方式

间隙锁是InnoDB在可重复读隔离级别下解决幻读的核心机制，但它是把「双刃剑」：

• 优点：彻底解决幻读，保证事务一致性；
• 缺点：范围过大时可能阻塞插入，影响并发性能。

使用口诀：
✅ 尽量用等值查询（减少间隙锁范围）；
✅ 必须为查询条件添加索引（避免锁表）；
✅ 长事务拆分成短事务（减少锁持有时间）；
✅ 幻读风险可控时，可调整为读提交隔离级别（牺牲一致性换性能）。

掌握间隙锁的底层逻辑，能让你在开发中更游刃有余地处理高并发场景下的数据一致性问题。下次遇到幻读问题，不妨想想是不是间隙锁在「默默守护」，或者是不是自己踩了「未使用索引」的坑～

如果觉得本文对你有帮助，欢迎点赞收藏，咱们评论区一起讨论更多数据库优化技巧！ 😊