通用：MySQL-InnoDB如何解决幻读问题——间隙锁

深度解析MySQL-InnoDB的Next-Key Lock：解决幻读的核心机制

在InnoDB的事务隔离级别中，可重复读（RR） 是默认级别，而它能彻底解决“幻读”问题的关键，正是依赖 Next-Key Lock（next-key锁） 机制。

一、先明确：Next-Key Lock是什么？

Next-Key Lock是InnoDB在行锁（Record Lock） 基础上扩展的一种“范围锁”，本质是“行锁 + 间隙锁（Gap Lock）”的组合：

• 行锁（Record Lock）：锁定表中“具体某一行数据”，防止其他事务修改或删除该行（如锁定product_id=5的行）；
• 间隙锁（Gap Lock）：锁定表中“不存在的行之间的间隙”，防止其他事务在该间隙中插入新数据（如锁定product_id=5与product_id=10之间的间隙）；
• Next-Key Lock：同时锁定“具体行”和“该行前后的间隙”，形成一个“连续的锁定范围”，既防止修改已有行，也防止插入新行。

核心目标：解决InnoDB在可重复读隔离级别下的“幻读”问题——避免事务A在同一事务内多次执行范围查询时，其他事务插入符合范围条件的新行，导致查询结果行数变化。

二、Next-Key Lock的工作原理：锁定范围如何计算？

InnoDB的Next-Key Lock锁定范围并非固定，而是根据“查询条件的索引值”和“表中已有数据的分布”动态确定，核心遵循“左开右闭区间”规则（即(左边界, 右边界]）。

2.1 基础场景：基于唯一索引的等值查询

当查询条件为“唯一索引的等值查询”（如主键、唯一键）时，InnoDB会先尝试锁定“匹配的行”，若表中存在该数据，则间隙锁会自动退化（仅保留行锁）；若不存在该数据，则仅锁定“对应的间隙”（无行锁）。

案例1：表中存在匹配数据（间隙锁退化）

假设products表的product_id是主键（唯一索引），表中已有数据：product_id=3,5,8。
事务A执行等值查询并加行锁：

BEGIN;
-- 等值查询主键=5，表中存在该数据
SELECT * FROM products WHERE product_id=5 FOR UPDATE;

Next-Key Lock的锁定范围：

• 初始锁定范围：根据左开右闭规则，锁定(3,5]区间（包含行product_id=5和3-5的间隙）；
• 间隙锁退化：因product_id=5是唯一索引且存在匹配行，InnoDB会自动删除“3-5的间隙锁”，最终仅保留“行锁（锁定product_id=5）”。

效果：

• 其他事务无法修改/删除product_id=5的行（行锁生效）；
• 其他事务可在3-5或5-8的间隙中插入新行（如product_id=4或6），因间隙锁已退化。

案例2：表中不存在匹配数据（仅锁定间隙）

同样基于products表（product_id=3,5,8），事务A执行等值查询：

BEGIN;
-- 等值查询主键=6，表中不存在该数据
SELECT * FROM products WHERE product_id=6 FOR UPDATE;

Next-Key Lock的锁定范围：

• 锁定范围：根据左开右闭规则，锁定(5,8]区间，但因product_id=6不存在，行锁不生效，仅保留“5-8的间隙锁”。

效果：

• 其他事务无法在5-8的间隙中插入新行（如product_id=6,7），防止后续事务A再次查询时出现“幻读”；
• 其他事务可修改product_id=5或8的行（无行锁）。

2.2 核心场景：基于非唯一索引的范围查询

当查询条件为“非唯一索引的范围查询”（如普通索引的BETWEEN、>、<）时，Next-Key Lock不会退化，会严格锁定“查询条件覆盖的范围”及“范围外的下一个间隙”，确保整个范围无新数据插入。

案例：非唯一索引的范围查询

假设products表的category_id是普通索引（非唯一），表中已有数据：category_id=2,2,5,7（存在重复值）。
事务A执行范围查询并加锁：

BEGIN;
-- 范围查询category_id BETWEEN 2 AND 5，非唯一索引
SELECT * FROM products WHERE category_id BETWEEN 2 AND 5 FOR UPDATE;

Next-Key Lock的锁定范围：

1. 先确定查询条件覆盖的索引值范围：2 ≤ category_id ≤5；
2. 根据左开右闭规则，锁定以下区间：
   • (-∞, 2]：锁定“小于2的间隙”和category_id=2的行（防止插入category_id=1）；
   • (2,5]：锁定“2-5的间隙”和category_id=5的行（防止插入category_id=3,4，并禁止修改category_id=5的行）；
   • (5,7]：额外锁定“5-7的间隙”（即使7不在查询范围内），防止插入category_id=6（避免事务A再次查询时出现幻读）。

效果：

• 其他事务无法修改category_id=2,5的行（行锁生效）；
• 其他事务无法在(-∞,2]、(2,5]、(5,7]的间隙中插入新行（如1,3,6），彻底杜绝幻读；
• 其他事务可修改category_id=7的行（仅锁定间隙，未锁定该行）。

2.3 特殊场景：基于非唯一索引的等值查询

当查询条件为“非唯一索引的等值查询”时，Next-Key Lock会锁定“所有匹配该值的行”及“这些行前后的间隙”，因非唯一索引可能存在多个匹配行，需防止插入新的匹配行。

案例：非唯一索引的等值查询

基于products表（category_id=2,2,5,7，普通索引），事务A执行等值查询：

BEGIN;
-- 等值查询category_id=2，非唯一索引（存在多个匹配行）
SELECT * FROM products WHERE category_id=2 FOR UPDATE;

Next-Key Lock的锁定范围：

• 锁定(-∞,2]：包含所有category_id=2的行（行锁）和“小于2的间隙”（防止插入category_id=1）；
• 锁定(2,5]：包含“2-5的间隙”（防止插入category_id=3,4），避免其他事务插入新的category_id=2（因非唯一索引可能插入在2和5之间）。

效果：

• 其他事务无法修改所有category_id=2的行；
• 其他事务无法在(-∞,2]和(2,5]的间隙中插入新行，确保事务A再次查询category_id=2时，行数不变（无幻读）。

三、Next-Key Lock的核心作用：彻底解决幻读

在可重复读隔离级别下，Next-Key Lock通过“锁定范围+禁止插入”的双重机制，从根源上解决幻读问题，我们通过一个完整的并发场景验证：

3.1 未使用Next-Key Lock的幻读场景（假设无间隙锁）

1. 事务A（可重复读隔离级别）：执行范围查询，查询category_id≤5的商品，返回3行（category_id=2,2,5）；

   BEGIN;
   SELECT * FROM products WHERE category_id ≤5; -- 返回3行
   

2. 事务B：插入一条category_id=3的新商品（因无间隙锁，插入成功）；

   BEGIN;
   INSERT INTO products (category_id, name) VALUES (3, '新商品'); -- 插入成功
   COMMIT;
   

3. 事务A：再次执行相同查询，返回4行（新增了category_id=3的行），出现幻读。

3.2 使用Next-Key Lock后的防幻读场景

1. 事务A（可重复读隔离级别）：执行范围查询并加锁，Next-Key Lock锁定(-∞,5]和(5,7]区间；

   BEGIN;
   SELECT * FROM products WHERE category_id ≤5 FOR UPDATE; -- 返回3行，加Next-Key Lock
   

2. 事务B：尝试插入category_id=3的新商品，因3在(2,5]的锁定间隙中，插入操作被阻塞（等待事务A释放锁）；
3. 事务A：再次执行相同查询，仍返回3行（无新行插入），幻读被彻底解决；
4. 事务A：提交事务，释放Next-Key Lock，事务B的插入操作才会继续执行。

四、实战避坑：Next-Key Lock可能引发的问题与解决方案

Next-Key Lock虽能解决幻读，但也可能因“锁定范围过大”导致锁等待超时或死锁，尤其在高并发场景下需特别注意。

4.1 问题1：间隙锁导致的锁等待超时

现象

两个事务分别对“相邻的间隙”执行加锁操作，因Next-Key Lock的锁定范围重叠，导致其中一个事务等待锁超时。

案例

products表product_id=3,5,8（主键），事务A和事务B分别执行：

1. 事务A：查询product_id=4（不存在）并加锁，锁定(3,5]间隙；

   BEGIN;
   SELECT * FROM products WHERE product_id=4 FOR UPDATE; -- 锁定(3,5]
   

2. 事务B：查询product_id=5（存在）并加锁，因5在事务A的(3,5]锁定范围内，事务B被阻塞，最终超时；

   BEGIN;
   SELECT * FROM products WHERE product_id=5 FOR UPDATE; -- 被阻塞，超时报错
   

解决方案

1. 尽量使用唯一索引的等值查询：唯一索引的等值查询会让间隙锁退化，减少锁定范围；
2. 缩小查询范围：避免对“不存在的索引值”执行加锁查询，尽量查询表中已存在的数据；
3. 降低隔离级别：若业务可接受“不可重复读”，可将隔离级别从REPEATABLE-READ改为READ-COMMITTED（RC级别下，InnoDB会关闭间隙锁，仅保留行锁）。

4.2 问题2：Next-Key Lock导致的死锁

现象

两个事务的Next-Key Lock锁定范围交叉，形成循环等待，最终触发死锁。

案例

products表category_id=2,5,7（普通索引），事务A和事务B分别执行：

1. 事务A：查询category_id BETWEEN 2 AND 5并加锁，锁定(-∞,2]、(2,5]、(5,7]；

   BEGIN;
   SELECT * FROM products WHERE category_id BETWEEN 2 AND 5 FOR UPDATE;
   

2. 事务B：查询category_id BETWEEN 5 AND 7并加锁，锁定(2,5]、(5,7]、(7,+∞)；

   BEGIN;
   SELECT * FROM products WHERE category_id BETWEEN 5 AND 7 FOR UPDATE;
   

3. 事务A需等待事务B释放(5,7]的锁，事务B需等待事务A释放(2,5]的锁，形成死锁，MySQL会自动回滚其中一个事务。

解决方案

1. 统一查询范围的顺序：所有事务对同一索引的范围查询，均按“从小到大”或“从大到小”的统一顺序执行，避免交叉锁定；
2. 拆分范围查询：将大的范围查询拆分为多个小的等值查询（利用唯一索引的间隙锁退化）；
3. 减少锁持有时间：事务内快速执行SQL并提交，避免长时间持有Next-Key Lock。

五、总结：Next-Key Lock的核心使用原则

1. 理解锁定范围是关键：Next-Key Lock的锁定范围遵循“左开右闭区间”，需根据“索引类型（唯一/非唯一）”和“数据存在性”判断最终锁定范围；
2. 唯一索引优先：唯一索引的等值查询会让间隙锁退化，减少锁竞争，是高并发场景的首选；
3. 隔离级别适配：
   • 核心业务（需防幻读）：使用REPEATABLE-READ级别，依赖Next-Key Lock保障一致性；
   • 高并发非核心业务（可接受不可重复读）：使用READ-COMMITTED级别，关闭间隙锁提升性能；
4. 避免大范围锁定：尽量避免对“不存在的索引值”或“超大范围”执行加锁查询，减少锁等待与死锁风险。

Next-Key Lock是InnoDB事务隔离性的“幕后功臣”，只有理解其底层逻辑与锁定规则，才能在保障数据一致性的同时，避免并发性能问题，让事务在高并发场景下稳定运行。