17370845950

间隙锁通过锁定索引记录间的“间隙”防止其他事务插入新记录，从而避免幻读。在REPEATABLE READ隔离级别下，执行范围查询时，InnoDB不仅锁定行记录，还锁定记录之间的间隙、首记录前和末记录后的范围。例如查询id BETWEEN 10 AND 20时，会锁定(5,12)和(12,25)等间隙（假设有id为5、12、25的记录），阻止其他事务插入id在该范围内的新行。间隙锁基于B+树索引实现，影响范围可能超出预期，增加锁冲突风险。实际应用中，可通过调整隔离级别至READ COMMITTED、优化索引设计、缩小事务范围、避免不必要的锁定、监控锁状态及分批处理等方式优化间隙锁带来的并发问题。

间隙锁（Gap Lock）是InnoDB存储引擎在实现特定事务隔离级别（主要是

REPEATABLE READ

）时，为了解决幻读（Phantom Read）问题而引入的一种锁机制。简单来说，它锁定的不是具体的某一行记录，而是索引记录之间的“间隙”，或者说是某个范围。这能有效防止新的记录被插入到这个被锁定的范围内，从而保证事务在多次读取同一范围数据时，看到的数据集是一致的。

间隙锁的出现，坦白讲，是数据库设计者在追求数据一致性与并发性之间找到的一个平衡点。当我们的事务需要确保在某个数据范围内，不会有新的数据凭空出现或消失时，间隙锁就发挥了它的作用。它解决了这样一个痛点：即便我们已经锁定了查询到的所有行记录，但在并发环境下，如果其他事务在这个范围里插入了新行，我们的后续查询依然会“看到”这些新行，这就是幻读。间隙锁正是为了弥补这种“空隙”而生的。

间隙锁是如何避免幻读（Phantom Read）的？

要理解间隙锁如何避免幻读，我们得先搞清楚幻读到底是什么。想象一下，你在一个银行系统里，先查询了所有余额在100到200之间的账户。如果此时，另一个柜员恰好新开了一个账户，余额是150，并提交了。那么当你再次查询同样范围的账户时，你会发现多了一个之前没见过的账户。这就是幻读，你的事务在逻辑上认为的“不变”被打破了。

间隙锁正是为了防止这种情况发生。当一个事务在

REPEATABLE READ

隔离级别下，执行一个范围查询并需要锁定这些数据（比如

SELECT ... WHERE id BETWEEN 10 AND 20 FOR UPDATE;

），InnoDB不仅仅会锁定

id

在10到20之间的所有现有记录，它还会锁定这些记录之间的“间隙”，以及10之前的间隙和20之后的间隙（如果它们是边界）。

具体来说，如果你的表里有

id

为5, 12, 25的记录，当你查询

id BETWEEN 10 AND 20

时，间隙锁会锁定：

• (5, 12)

  这个间隙：防止新的

  id

  在5到12之间插入。

• (12, 25)

  这个间隙：防止新的

  id

  在12到25之间插入。
• 如果查询范围是

  id > 10

  ，那么它会锁定

  (10, 12)

  ，

  (12, 25)

  ，以及

  (25, +∞)

  。

这样一来，无论其他事务尝试在

(5, 12)

或

(12, 25)

这两个区间内插入任何新记录，都会被当前事务的间隙锁阻塞，直到当前事务提交或回滚。这确保了在当前事务的生命周期内，你再次执行相同的范围查询时，不会看到任何“凭空出现”的新行，从而有效杜绝了幻读。

间隙锁的工作原理与影响范围是怎样的？

间隙锁的工作原理，说白了，就是InnoDB利用了B+树索引的特性。它不是在内存中画一个“锁定的区域”，而是通过在索引结构中的特定位置设置锁标记来实现的。当一个事务需要锁定某个范围时，InnoDB会找到这个范围的起始和结束索引键值，然后锁定这些键值所代表的记录以及它们之间的“空隙”。值得注意的是，间隙锁是作用于索引的，所以一个高效的索引设计对于间隙锁的性能至关重要。

间隙锁的影响范围，有时候会超出我们的预期，这正是它可能导致死锁和并发问题的原因。它会锁定：

1. 索引记录之间的间隙：这是最核心的部分。
2. 第一个索引记录之前的间隙：如果你的查询范围从索引的最小值开始，或者查询的起始值小于表中最小的索引值，那么从负无穷到第一个索引记录之间的间隙也会被锁定。
3. 最后一个索引记录之后的间隙：同理，如果查询范围到索引的最大值结束，或者查询的结束值大于表中最大的索引值，那么从最后一个索引记录到正无穷之间的间隙也会被锁定。

举个例子，假设我们有一个

users

表，

id

列是主键，有数据

id = 1, 5, 10, 15

。 如果一个事务执行

SELECT * FROM users WHERE id > 7 AND id < 12 FOR UPDATE;

那么，InnoDB会锁定：

• 记录

  id=10

  （这是一个行锁）。

• (5, 10)

  这个间隙。

• (10, 15)

  这个间隙。 这意味着，在事务提交前，其他事务无法插入

  id

  为6、7、8、9、11、12、13、14的记录。可以看到，间隙锁锁定了一个比我们查询结果更大的范围，这在某些高并发场景下，确实会增加锁冲突的可能性。

在实际应用中，我们应该如何理解和优化间隙锁？

理解间隙锁的机制，对于编写高性能、无死锁的SQL至关重要。在实际应用中，我们经常会遇到因为间隙锁导致的并发问题，比如死锁或者事务长时间等待。

1. 何时触发间隙锁？

   • 在

     REPEATABLE READ

     隔离级别下。
   • 当执行范围查询（

     WHERE col > X AND col < Y

     ，

     WHERE col LIKE 'prefix%'

     等）时。
   • 当对非唯一索引进行等值查询，且查询条件命中了多个记录，或者没有命中任何记录时，也会产生间隙锁。比如

     SELECT * FROM users WHERE status = 'pending' FOR UPDATE;

     如果

     status

     是非唯一索引，并且有很多

     pending

     的记录，那么这些记录以及它们之间的间隙都会被锁定。

   • INSERT

     操作在某些情况下也会产生间隙锁，例如在插入新记录时，为了检查唯一性约束，可能会锁定插入位置附近的间隙。

2. 优化策略：

   • 考虑隔离级别： 如果你的业务场景能够接受较低的隔离级别（例如

     READ COMMITTED

     ），并且幻读不是一个核心问题，那么切换到

     READ COMMITTED

     可以完全禁用间隙锁（但仍会保留行锁）。这能显著提高并发性，但需要权衡数据一致性风险。
   • 精准索引设计： 确保你的查询能够尽可能地利用索引，并且查询条件能够精确匹配索引，避免全表扫描或大范围的索引扫描。对于唯一索引的等值查询，InnoDB只会加行锁，不会有间隙锁。
   • 缩小事务范围： 尽量让事务简短，减少锁持有的时间。长时间运行的事务，尤其是涉及范围查询的，会长时间持有间隙锁，极大地影响并发。
   • 避免不必要的锁定： 只有在确实需要防止幻读或数据不一致时，才使用

     FOR UPDATE

     或

     LOCK IN SHARE MODE

     。
   • 监控锁情况： 使用

     SHOW ENGINE INNODB STATUS

     可以查看当前的锁等待和死锁信息，帮助我们定位和分析间隙锁引起的问题。通过分析

     LATEST DETECTED DEADLOCK

     部分，我们可以看到是哪些事务、哪些SQL语句因为间隙锁而发生了死锁。
   • 批量操作： 对于需要更新或删除大量数据的操作，考虑分批处理，每次处理一小部分数据，可以减少单次事务持有间隙锁的时间和范围。

间隙锁是一个强大的工具，它在保证数据一致性方面功不可没，但同时它也是一把双刃剑，不恰当的使用或不理解其工作原理，很容易导致性能瓶颈。所以，深入理解它，并结合业务场景进行优化，是我们每个开发者都需要掌握的技能。