从S锁/X锁到Next-Key Lock：MySQL锁机制硬核拆解-洪萨配资

从 S 锁 / X 锁到 Next-Key Lock：MySQL InnoDB 锁机制硬核拆解

MySQL 的 InnoDB 引擎锁机制是面试和生产中高频考点，尤其是幻读如何被解决、Next-Key Lock到底锁了什么、加锁规则如何判断等。下面从基础到进阶，一层层拆解。

1. 锁的分类总览（InnoDB 核心）

InnoDB 锁主要分三层：

表级锁（意向锁为主）
行级锁（最重要，Record / Gap / Next-Key）
页级锁（基本不用）

重点关注行级锁的三种形态 + 两种模式：

锁类型	英文名	模式（Mode）	作用	是否允许其他事务读写
共享锁	Shared Lock	S	允许读，不允许写	其他事务可加 S，不允许加 X
排他锁	Exclusive Lock	X	允许读 + 写，不允许其他事务读写	其他事务都阻塞

S/X 是锁的“权限”，而 Record/Gap/Next-Key 是锁的范围。

2. 三种行锁范围（锁住什么）

锁名称	英文名	锁住范围	典型场景	是否防幻读
记录锁	Record Lock	仅仅锁住一条索引记录本身	唯一索引 + 等值查询（主键/唯一索引）	×
间隙锁	Gap Lock	锁住索引记录之间的间隙（不含记录本身）	防止在间隙中插入新记录	√（部分）
临键锁	Next-Key Lock	记录 + 它前面的间隙（左开右闭）	InnoDB RR 隔离级别下默认加的锁	√（最强）

关键记忆：

Next-Key Lock =Record Lock + Gap Lock
锁定形式：(gap 前) ← record → (gap 后)→ 但实际是前开后闭，锁住 record 本身 + record前面的间隙

3. S/X 与 Record/Gap/Next-Key 的组合

S 型 Record Lock：共享记录锁
X 型 Record Lock：排他记录锁
S 型 Gap Lock：共享间隙锁（较少见）
X 型 Gap Lock：排他间隙锁（最常见防插入）
S 型 Next-Key Lock：共享临键锁（SELECT … LOCK IN SHARE MODE）
X 型 Next-Key Lock：排他临键锁（SELECT … FOR UPDATE / UPDATE / DELETE 默认）

4. 为什么需要 Gap Lock 和 Next-Key Lock？——幻读的根源

幻读定义（ANSI SQL 标准）：
同一事务内，前后两次范围查询，结果集行数不同（主要是插入导致）。

快照读（普通 SELECT）靠 MVCC 解决不可重复读，但无法防插入→ 因此防不了幻读。

当前读（SELECT … FOR UPDATE / LOCK IN SHARE MODE / UPDATE / DELETE）会加锁。

InnoDB 在Repeatable Read（默认隔离级别）下，通过Next-Key Lock实现当前读防幻读。

5. Next-Key Lock 加锁规则（面试最爱问）

核心规则（InnoDB RR 级别下）：

加锁对象：走的是哪个索引，就在哪个索引上加锁（聚簇索引 / 辅助索引）
默认使用：Next-Key Lock（前开后闭）
唯一索引 + 等值命中→退化为 Record Lock（优化）
非唯一索引 / 范围查询→ 保持Next-Key Lock
等值查询命中多条→ 最后一跳退化为 Gap Lock（右边界不锁记录）
插入意向锁（Insert Intention Lock）：插入时会在间隙中加的意向锁，不阻塞其他插入意向锁，但会被普通 Gap Lock 阻塞

经典例子（假设表 t 有字段 id 主键，c 非唯一索引）

CREATETABLEt(idINTPRIMARYKEY,cINT,KEYidx_c(c));INSERTINTOtVALUES(5,10),(10,20),(15,30);

事务 A：

BEGIN;SELECT*FROMtWHEREc=15FORUPDATE;

加锁分析：

在 idx_c 上找到 c=15 的记录
加X 型 Next-Key Lock：(10, 15]
- 锁住 15 这条记录（Record Lock）
- 锁住 (10,15) 的间隙（Gap Lock）

事务 B能做什么？

INSERT c=12 → 被阻塞（落入间隙）
INSERT c=15 → 被阻塞（记录本身被 X 锁）
INSERT c=20 → 可插入（不在范围内）
UPDATE c=15 的行 → 被阻塞
SELECT c=15 的行 → 普通读可（MVCC），当前读阻塞

6. 常见场景加锁总结表

操作类型	隔离级别	索引情况	加锁类型（默认）	防幻读？
SELECT … FOR UPDATE	RR	非唯一索引 + 范围	Next-Key Lock	是
SELECT … FOR UPDATE	RR	唯一索引 + 等值命中	Record Lock	否（但当前读安全）
UPDATE / DELETE	RR	非唯一索引	Next-Key Lock	是
INSERT	-	-	插入意向锁（不互斥插入）	-
SELECT … (快照读)	RR / RC	-	无锁（MVCC）	否
RC 隔离级别	RC	-	仅 Record Lock	否

7. 为什么 RC 不防幻读，而 RR 能防？

RC：每次当前读都生成新 ReadView + 只加 Record Lock → 允许其他事务插入 → 幻读可能
RR：事务开始后 ReadView 固定 + 默认 Next-Key Lock → 范围读时锁住间隙 → 防插入 → 防幻读

8. 生产中常见“坑”

唯一索引降级 Record Lock → 无法完全防幻读（但当前读本身安全）
死锁常见：Next-Key Lock 之间互斥（尤其是非唯一索引范围操作）
大事务 + 范围 FOR UPDATE → 容易锁全表（或很大范围）
降级方案：用READ COMMITTED（关闭 Next-Key Lock）+ 业务补齐防重

一句话总结：

InnoDB 通过S/X 控制读写权限，用Record Lock 锁行，用Gap Lock 锁间隙，最终用Next-Key Lock（Record + 前间隙）在RR 隔离级别下实现了当前读防幻读，这是 MySQL 与传统数据库在隔离级别实现上的最大区别之一。

想看具体死锁案例、锁等待分析（information_schema）、还是间隙锁导致的性能问题优化？可以继续深挖～