在 MySQL 数据库开发中，“幻读” 和 “间隙锁” 是两个高频出现却又容易混淆的概念。尤其是在高并发场景下，理解这两者的关系及工作机制，对避免数据一致性问题和性能瓶颈至关重要。本文将从基础概念出发，结合实际案例解析幻读的产生原因、间隙锁的工作原理，以及两者如何协同保障数据安全。
一、先搞懂：什么是幻读？
很多开发者会把 “幻读” 和 “不可重复读” 混为一谈，但实际上二者有本质区别。
1. 幻读的定义
幻读是指在同一事务中，两次执行相同的查询语句，第二次查询结果中出现了第一次查询时不存在的新数据（“新增” 的行），或者原有数据消失（“删除” 的行）。
注意：幻读的核心是 “新插入的行”，而不可重复读主要针对 “已有行的修改”。例如：
- 不可重复读：事务 A 第一次查询某行数据为 100，事务 B 修改为 200 并提交，事务 A 再次查询变为 200。
- 幻读：事务 A 第一次查询 “年龄> 20” 的用户有 3 条，事务 B 插入 1 条年龄 25 的新用户并提交，事务 A 再次查询变为 4 条。
2. 幻读的产生场景（实例演示）
为了更直观理解，我们通过一个实例演示幻读的产生过程。
假设存在一张用户表user，表结构及初始数据如下：
TypeScript取消自动换行复制
CREATE TABLE `user` (
`id` int(11) NOT NULL PRIMARY KEY AUTO_INCREMENT,
`age` int(11) NOT NULL,
`name` varchar(20) NOT NULL,
KEY `idx_age` (`age`) -- 基于age创建索引
-- 插入数据
INSERT INTO user (age, name) VALUES (10, 'a'), (20, 'b'), (30, 'c');
在可重复读（RR）隔离级别下，执行如下操作：
时间点 |
事务 A |
事务 B |
T1 |
BEGIN; |
- |
T2 |
SELECT * FROM user WHERE age > 20; -- 结果：(30, 'c') |
- |
T3 |
- |
BEGIN; |
T4 |
- |
INSERT INTO user (age, name) VALUES (25, 'd'); -- 插入成功 |
T5 |
- |
COMMIT; |
T6 |
SELECT * FROM user WHERE age > 20; -- 结果：(30, 'c'), (25, 'd') |
- |
事务 A 在 T2 和 T6 两次查询的结果不一致（新增了 (25, 'd')），这就是典型的幻读。
二、为什么会产生幻读？
幻读的本质是：当前事务未锁定 “未来可能插入的数据” 所在的区间，导致其他事务可以插入新数据，从而破坏事务的一致性视图。
在 MySQL 中，不同隔离级别的幻读表现不同：
- 读未提交（RU）/ 读已提交（RC）：由于不保证 “可重复读”，幻读必然存在；
- 可重复读（RR）：MySQL 通过 “间隙锁” 解决了大部分幻读场景；
- 串行化（Serializable）：通过强制事务串行执行避免幻读，但性能极差。
日常开发中，我们通常使用 RR 隔离级别，因此间隙锁成为解决幻读的核心机制。
三、间隙锁：解决幻读的 “区间守卫”
1. 间隙锁的定义
间隙锁（Gap Lock）是 MySQL 在 RR 隔离级别下，为解决幻读引入的锁机制。它锁定的是 “索引记录之间的间隙”，而非具体的行，目的是防止其他事务在该间隙中插入新数据。
例如，在上述user表中，age 索引存在 10、20、30 三个值，其间隙包括：
- (-∞, 10)
- (10, 20)
- (20, 30)
- (30, +∞)
当事务 A 对age > 20的行加锁时，MySQL 会对 (20, 30) 和 (30, +∞) 这两个间隙加锁，阻止其他事务插入 age 在该区间的新数据。
2. 间隙锁的工作机制（结合实例）
我们基于上述user表，在 RR 隔离级别下测试间隙锁的作用：
时间点 |
事务 A |
事务 B |
T1 |
BEGIN; |
- |
T2 |
SELECT * FROM user WHERE age > 20 FOR UPDATE; -- 加锁查询 |
- |
T3 |
- |
BEGIN; |
T4 |
- |
INSERT INTO user (age, name) VALUES (25, 'd'); -- 阻塞！ |
T5 |
- |
INSERT INTO user (age, name) VALUES (35, 'e'); -- 阻塞！ |
T6 |
COMMIT; -- 释放锁 |
- |
T7 |
- |
阻塞解除，插入成功 |
现象解析：
- 事务 A 执行SELECT ... FOR UPDATE时，不仅锁定了 age=30 的行，还对 (20,30) 和 (30, +∞) 两个间隙加了间隙锁；
- 事务 B 插入 age=25（属于 (20,30) 间隙）和 age=35（属于 (30, +∞) 间隙）时，被间隙锁阻塞，直到事务 A 提交释放锁；
- 因此，事务 A 再次查询时不会出现新数据，幻读被避免。
3. 间隙锁的关键特性
（1）基于索引锁定：间隙锁仅在 “有索引” 的列上生效。如果查询条件使用非索引列，MySQL 会触发 “全表扫描”，并对整个表的所有间隙加锁（即 “表级锁”），严重影响性能。
（2）与行锁结合形成临键锁（Next-Key Lock）：
MySQL 中，间隙锁不会单独存在 —— 它会与 “行锁” 结合形成临键锁（Next-Key Lock），即 “行锁 + 间隙锁”。
例如，对 age=20 的行加临键锁时，实际锁定的是：
- 行锁：age=20 的行；
- 间隙锁：(10, 20) 的间隙。
（3）间隙锁是 “单向” 的，且不冲突：
两个事务可以同时对同一间隙加间隙锁（不会冲突），但插入操作会被间隙锁阻塞。
四、间隙锁的 “副作用”：死锁风险
间隙锁虽然解决了幻读，但也可能导致死锁。例如：
时间点 |
事务 A |
事务 B |
T1 |
BEGIN; |
BEGIN; |
T2 |
SELECT * FROM user WHERE age = 25 FOR UPDATE; -- 锁定 (20,30) 间隙 |
- |
T3 |
- |
SELECT * FROM user WHERE age = 25 FOR UPDATE; -- 锁定 (20,30) 间隙（不冲突） |
T4 |
INSERT INTO user (age, name) VALUES (25, 'd'); -- 等待事务 B 释放间隙锁 |
- |
T5 |
- |
INSERT INTO user (age, name) VALUES (25, 'e'); -- 等待事务 A 释放间隙锁 |
此时，事务 A 和事务 B 相互等待对方释放间隙锁，导致死锁。
解决思路：
- 避免在同一事务中对多个间隙加锁；
- 尽量使用 “唯一索引”（唯一索引的间隙锁会降级为行锁，减少锁定范围）；
- 合理设计索引，缩小锁定区间。
五、实战总结：间隙锁与幻读的开发注意事项
- 明确 RR 隔离级别的幻读防护范围：
MySQL 的 RR 隔离级别通过间隙锁解决了 “通过索引加锁查询” 的幻读，但对 “无索引的查询” 或 “非锁定读”（不加 FOR UPDATE/SHARE）仍可能出现幻读。
- 索引设计是关键：
- 必须为查询条件设计合理的索引，否则间隙锁会退化为表锁；
- 优先使用唯一索引，减少间隙锁范围。
- 控制锁定范围：
- 避免使用WHERE age > 10这类大范围条件，改为WHERE age BETWEEN 10 AND 20缩小锁定区间；
- 非必要不使用FOR UPDATE，减少加锁概率。
- 警惕间隙锁的死锁：
- 对同一组数据的操作，保持一致的加锁顺序；
- 开启死锁检测（innodb_deadlock_detect = ON），并设置合理的锁等待超时（innodb_lock_wait_timeout）。
六、最后：一句话说清核心关系
幻读是 “新数据插入导致的查询结果不一致”，间隙锁是 “锁定数据间隙阻止新插入” 的机制，二者在 RR 隔离级别下形成 “问题 - 解决方案” 的对应关系。
掌握间隙锁与幻读的原理，不仅能避免数据一致性问题，更能在高并发场景下平衡性能与安全 —— 这也是区分初级和中高级 MySQL 开发者的重要标志。
