MySQL记录锁与间隙锁的区别及应用场景

记录锁只会锁住已经存在的索引记录，间隙锁则用于锁定两个索引值之间的空白区间以阻止新数据插入；当使用非唯一索引进行等值查询时，二者通常会组合成临键锁。要准确判断 MySQL InnoDB 当前使用的是哪种锁，需要通过SHOW ENGINE INNODB STATUS确认，而且具体加锁方式还会受到事务隔离级别与索引类型的共同影响。

记录锁只锁已存在的索引行，不会锁定索引间隙

记录锁（Record Lock）是 InnoDB 中真正意义上“锁某一行”的最小粒度锁，但它锁住的并不是物理数据行本身，而是该行在**聚簇索引或二级索引中的对应索引记录**。只要 SQL 条件能够命中索引，尤其是主键索引或唯一索引，并且精确匹配到某条已存在的数据，InnoDB 通常只会加记录锁。

常见触发场景：

• SELECT * FROM users WHERE id = 10 FOR UPDATE; —— id 是主键，命中后只锁该条索引记录
• UPDATE orders SET status = 'paid' WHERE order_no = 'ORD-2026-001'; —— order_no 是唯一索引，也只会锁对应记录

关键点：如果没有走索引，MySQL InnoDB 的加锁范围可能显著扩大；如果查询没有找到目标记录，也不会产生记录锁——此时更有可能出现的是间隙锁。

间隙锁只锁“空白区间”，核心作用是防止插入新数据

间隙锁（Gap Lock）不会锁住任何真实存在的数据行，它锁定的是**两个索引值之间的空隙范围**，通常可以表示为左开右开的区间，例如 (10, 20)。它的主要目的只有一个：阻止其他事务在这个索引区间内执行 INSERT，从而避免幻读问题。

典型触发条件：

• 事务隔离级别通常需要是 REPEATABLE READ（在 READ COMMITTED 下默认不会启用大多数间隙锁）
• 查询使用了**非唯一索引**或**范围查询条件**，并且扫描范围覆盖到了索引间隙
• 例如：SELECT * FROM users WHERE age BETWEEN 25 AND 35 FOR UPDATE; —— 即使表里不存在 age=28 的记录，也可能锁住 (25, 35) 这段间隙

需要注意的是：SELECT ... FOR UPDATE、UPDATE、DELETE 都可能触发间隙锁，而普通的 SELECT（一致性非锁定读）通常不会加这种锁。

等值查询非唯一索引时，记录锁和间隙锁往往会同时出现

这是 MySQL 锁机制实战中最容易让人困惑的地方之一。只要查询条件基于非唯一索引进行等值匹配（例如 WHERE status = 'pending'），InnoDB 加的通常就不只是单纯的记录锁：它会先对每个命中的索引记录加锁，再把这些记录前后的索引间隙一并锁住，最终形成的就是临键锁（Next-Key Lock）。

举例说明：

• 表 orders 上有非唯一索引 idx_status(status)，当前存在 status='pending' 的记录，对应索引值分别为：20、25、30
• 执行 SELECT * FROM orders WHERE status = 'pending' FOR UPDATE;
• 实际加锁范围可能包括：(15,20]、(20,25]、(25,30]、(30,35]（假设相邻索引值为 15 和 35）

也就是说，看起来你只是锁住了三条 pending 记录，实际上连这些记录之间的空隙，以及前后相邻索引值之间的区域也一起被锁住了。这也是为什么 MySQL 中看似简单的等值查询，在高并发场景下反而容易造成插入阻塞。

判断当前到底加了哪种锁，要看 SHOW ENGINE INNODB STATUS 输出

执行完相关加锁 SQL 后，可以在另一个会话中运行 SHOW ENGINE INNODB STATUSG，重点查看 TRANSACTIONS 段中的 RECORD LOCKS 相关内容：

• 包含 locks rec but not gap → 表示纯记录锁
• 包含 locks gap before rec → 表示间隙锁（或临键锁中的间隙部分）
• 同时出现 locks rec but not gap 和 locks gap before rec → 通常说明表现为临键锁

不要只依赖 explain 或执行计划去推测锁类型——真正可靠的判断依据，是 INNODB STATUS 中展示的锁结构信息，这才是 MySQL 实际加锁行为的直接证据。

最容易被忽略的一点是：间隙锁是否会出现，根本上取决于事务隔离级别和索引类型，而不只是 SQL 写法本身。比如同样一句 WHERE age = 25，在 READ COMMITTED 下，可能根本不会触发间隙锁；但如果切换到 REPEATABLE READ，就有可能把整段空白索引区间一起锁住。因此在系统上线前，一定要在目标数据库隔离级别下实际验证锁行为，这一步非常关键，不能省略。