MySQL InnoDB锁机制之从Record到Next-Key的使用解读

在真实业务中，你遇到的大多数 MySQL 性能问题、死锁问题，几乎都与“锁”有关。但很多工程师对锁的理解停留在碎片层面：

知道“行锁”“间隙锁”“next-key-lock”，但不知道 SQL 是如何触发这些锁的、锁到底锁在哪里、为什么会锁这么多。

这一篇文章，我会用工程化思维，带你一次性理解 InnoDB 锁机制的全景图。

看完以后，你将具备：

• ✔ 能看懂锁的真实作用
• ✔ 能从 SQL 推断出锁范围
• ✔ 能解释死锁发生原因
• ✔ 能在面试中条理清晰地讲出锁机制

一、为什么 InnoDB 的锁机制这么复杂？

MySQL 采用 MVCC + 锁 实现事务隔离，其中最关键的隔离级别是：

• RC：读已提交
• RR：可重复读（默认）

RR 是企业最常见的隔离级别，它要解决“幻读”问题。

于是有了三个锁：

• 记录锁（Record Lock）
• 间隙锁（Gap Lock）
• Next-Key Lock（Record + Gap）

所有复杂问题都来自这个组合。

二、InnoDB 的三种核心锁（理解它们的作用和触发条件）

Record Lock：真实行上的锁

• 锁的对象：一条真实存在的记录
• 触发场景：精确命中唯一索引

例如：

SELECT * FROM user WHERE id = 10 FOR UPDATE;

只锁 (10] —— 单条记录。

特点：不会锁间隙，因此不会阻止插入。

Gap Lock：只锁“间隙”，不锁数据

作用：阻止“间隙内插入新数据”，防止幻读。

例如：

索引中已有值：

10 --- 20 --- 30

SQL：

SELECT * FROM user WHERE age > 20 FOR UPDATE;

Gap Lock 会锁住：

(20, 30)
(30, +∞)

重点：Gap Lock 不锁记录，只锁区间。

Next-Key Lock：Record + Gap 的组合锁

RR 下范围查询的默认锁模式：

(prev_key, record_key]

例如：（假设索引有 10、20、30）

SELECT * FROM t WHERE age BETWEEN 15 AND 25 FOR UPDATE;

锁住的区间：

(10,20]
(20,30]

作用：

• ✔ 锁住命中的记录
• ✔ 锁住记录前的 gap → 阻止插入

这就是为什么 RR 隔离级别能规避幻读。

三、锁到底由哪些 SQL 触发？

“ SQL → 锁类型” 映射表：

一句话总结：

• 能精确锁住记录 → Record Lock
• 需要范围扫描 → Next-Key Lock
• 范围扫描一定会锁 gap → Gap Lock

四、锁具体加在什么区间？

假设索引中有如下值：

10 ---- 20 ---- 30 ---- 40

来看不同 SQL 加的锁👇

WHERE id = 20 FOR UPDATE

锁：

(10, 20]

但如果字段是主键/唯一键，会优化成：

[20]

WHERE id > 20 FOR UPDATE

锁：

(20,30)
(30,40)
(40,+∞)

WHERE id BETWEEN 15 AND 35 FOR UPDATE

锁：

(10,20]
(20,30]
(30,40]

无索引条件

SELECT * FROM user WHERE name='xxx' FOR UPDATE;

锁住所有记录：

[10], [20], [30], [40]

→ 大量锁冲突发生的根源。

五、总结

• InnoDB 的锁永远基于索引。
• 无法精确匹配记录，就会使用 Next-Key Lock。
• 范围查询一定会带 gap 锁。

掌握这三点后，死锁、锁等待、幻读问题都能一眼看穿。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

最新评论