深入解析临键锁（Next-Key Lock）：定义、范围与实践意义

原创于 2025-11-28 08:11:59 发布 · 980 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #java #mybatis

数据库专栏收录该内容

57 篇文章

订阅专栏

在数据库并发控制领域，锁机制是保障数据一致性的核心手段。当多个事务同时对数据进行读写操作时，不合理的锁策略可能导致脏读、不可重复读、幻读等问题。临键锁（Next-Key Lock）作为InnoDB存储引擎中至关重要的锁类型，正是为解决幻读问题而生，它结合了记录锁与间隙锁的特性，形成了独特的锁范围控制逻辑。本文将从定义出发，详细剖析临键锁的锁范围，并结合实际场景说明其应用价值。

一、临键锁的核心定义：记录锁与间隙锁的“结合体”

要理解临键锁，首先需要明确其与另外两种基础锁类型的关联——记录锁（Record Lock）和间隙锁（Gap Lock）。记录锁是直接作用于数据表中某一行具体记录的锁，仅锁定当前记录，不会影响相邻记录；间隙锁则是作用于记录之间“间隙”的锁，它不锁定具体记录，而是锁定两个记录之间的空白区域，防止其他事务在该间隙中插入新数据。

临键锁正是这两种锁的组合体，其官方定义为：一种锁定索引记录本身以及该记录之前间隙的锁。从本质上来说，临键锁是InnoDB在可重复读（Repeatable Read）隔离级别下（这也是InnoDB的默认隔离级别），为了避免幻读而默认采用的锁策略。它通过同时锁定“具体记录”和“记录前的间隙”，既保证了当前事务对目标记录的独占访问，又阻止了其他事务在相邻间隙中插入新记录，从而从根本上解决了幻读问题。

需要特别注意的是，临键锁是基于索引工作的。如果查询语句没有使用索引，InnoDB会采用全表扫描的方式，此时会对表中所有记录的临键锁进行锁定，相当于将整个表“锁住”，这会严重影响数据库的并发性能。因此，合理建立和使用索引是临键锁高效工作的前提。

二、临键锁的锁范围：“左开右闭”的区间逻辑

临键锁的核心特性体现在其锁范围的界定上，它遵循“左开右闭”的区间规则。这里的“区间”是基于索引值划分的，我们可以通过具体的索引数据案例来直观理解这一范围。

1. 基础场景：基于有序索引的锁范围划分

假设某数据表user中存在索引id，且该索引下的取值为：10、20、30、40、50（这些值按升序排列）。此时，InnoDB会将整个索引空间划分为多个连续的区间，每个区间对应一个临键锁的潜在范围，具体划分如下：

(-∞, 10]
(10, 20]
(20, 30]
(30, 40]
(40, 50]
(50, +∞]

从上述区间可以看出，每个临键锁的范围都是以一个索引值为“右边界”，且右边界是闭合的；左边界则是前一个索引值，且左边界是开放的。当事务对某个索引值进行操作时，会锁定该索引值所在的整个临键区间。

2. 具体案例：不同操作对应的临键锁范围

为了更清晰地说明锁范围，我们结合具体的SQL操作进行分析。假设当前事务T1执行以下SQL语句：


SELECT * FROM user WHERE id = 30 FOR UPDATE;

由于该语句使用了索引id，且操作目标为id=30，此时InnoDB会为事务T1分配临键锁，其锁范围为(20, 30]。这个范围包含两部分：一是间隙(20, 30)，二是记录id=30。这意味着：

其他事务无法修改id=30这条记录（记录锁的作用）；
其他事务无法在id=20和id=30之间插入新的记录（如id=25），也无法插入id=30的记录（间隙锁的作用）。

再假设事务T1执行的SQL语句为范围查询：


SELECT * FROM user WHERE id BETWEEN 20 AND 40 FOR UPDATE;

此时，事务T1会锁定与查询范围相关的所有临键区间，即(10, 20]、(20, 30]、(30, 40]。这样一来，其他事务既无法修改id为20、30、40的记录，也无法在10到40之间的任何间隙中插入新记录，从而有效避免了幻读。

3. 特殊情况：索引值不存在时的锁范围

如果事务操作的索引值在表中不存在，临键锁的范围依然遵循“左开右闭”规则，但会锁定包含该不存在值的区间。例如，表中id的取值仍为10、20、30、40、50，事务T1执行以下语句：


SELECT * FROM user WHERE id = 25 FOR UPDATE;

由于id=25不存在，InnoDB会找到包含25的临键区间，即(20, 30]，并对该区间加锁。此时，其他事务无法在20到30之间插入id=25的记录，也无法修改id=30的记录，这一机制同样是为了防止后续插入操作导致幻读。

三、临键锁的实践意义：解决幻读与平衡并发

在可重复读隔离级别下，幻读是指同一事务内多次执行相同的范围查询，第二次查询结果比第一次多了新插入的记录。临键锁通过“锁定记录+锁定间隙”的双重策略，从根源上解决了幻读问题。例如，当事务T1执行“SELECT * FROM user WHERE id BETWEEN 20 AND 40”后，即使其他事务试图在该区间插入id=25的记录，也会被临键锁阻塞，从而保证T1再次执行相同查询时，结果与第一次一致。

与此同时，临键锁的“左开右闭”范围设计也在一定程度上平衡了并发性能。它并非盲目地锁定整个表，而是仅锁定与操作相关的索引区间，使得其他事务可以正常访问区间外的数据，减少了锁冲突，提升了数据库的并发处理能力。

需要注意的是，在某些场景下可以通过调整隔离级别或使用特定SQL语法来规避临键锁。例如，将隔离级别降低到读已提交（Read Committed），InnoDB会自动关闭间隙锁，仅使用记录锁；或者使用“FOR UPDATE SKIP LOCKED”语法跳过已锁定的记录，适用于非核心业务的并发查询场景。但这些调整需要基于对业务需求和数据一致性要求的精准判断，避免因规避锁而引入数据安全风险。