MySQL 8.4 READ COMMITTED 怎么减少间隙锁：隔离级别、幻读与回归核对

订单服务高峰期经常会碰到一类很难复现的锁等待问题：事务A本来只想锁定一段不存在的订单号区间，结果事务B往这个范围里插新订单直接卡住查半天，最后在 data_locks 里看到的还不是普通行锁，是带gap标记的锁等待。不少团队碰到这种情况第一反应就是调低事务隔离级别，但这里得先把话说在前头：READ COMMITTED 能减少部分间隙锁，不等于完全取消并发控制，也替代不了唯一键约束和显式加锁读的作用。

先把等待现场还原：锁住的是行，还是行之间的空档

准备一张使用 InnoDB 的订单表，主键中间故意留出空号：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  state VARCHAR(20) NOT NULL,
  created_at DATETIME NOT NULL,
  KEY idx_orders_user_id (user_id)
) ENGINE = InnoDB;

INSERT INTO orders (id, user_id, state, created_at) VALUES
  (100, 7, 'paid',  '2026-08-18 09:00:00'),
  (120, 8, 'pending','2026-08-18 09:01:00');

连接 A 使用默认隔离级别，在事务里锁定一个范围：

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT id FROM orders WHERE id > 100 AND id 

查询没有返回任何行，但连接 A 仍可能把 100 与 120 之间的索引区间锁住。此时连接 B 执行：

INSERT INTO orders (id, user_id, state, created_at)
VALUES (110, 9, 'pending', '2026-08-18 09:02:00');

如果连接 B 进入等待状态，别只盯着客户端的“卡住”提示判断问题。MySQL 8.4 可以从 Performance Schema 读取锁对象和等待关系，重点观察锁类型是否带有 GAP、请求线程是否处于等待状态。

为什么 REPEATABLE READ 会把空档也纳入保护范围

InnoDB 的 next-key lock 可以理解为“记录锁加前面的间隙锁”。默认的 REPEATABLE READ 使用这类锁来避免同一事务内的范围读取出现幻行：第一次查不到某个范围内的记录，别的事务就不能悄悄插入一行让第二次查询看到不同结果。

这里有一个很容易混淆的点：普通一致性读取，例如不带 FOR UPDATE 的 SELECT，走的是 MVCC 快照逻辑；真正让插入被挡住的通常是锁定读取、更新或删除路径。碰到“范围查询慢”的情况，先把 SQL 是否带锁、索引是否按预期使用、事务是否迟迟不提交这几个点分开排查。

在单个会话切到 READ COMMITTED，再做同一组对照

先回滚连接 A 的事务，再只在该连接设置新的隔离级别。这样不会把全局连接池里的所有请求一起改变配置：

ROLLBACK;
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT id FROM orders WHERE id > 100 AND id 

连接 B 再次尝试插入 110。在普通范围锁场景下，等待通常会减少，因为 READ COMMITTED 不像默认级别那样普遍使用间隙锁来保护搜索范围。但这不是“所有 gap 都消失”：外键约束检查、重复键检查以及某些写入路径仍可能需要间隙锁。

如果业务代码依赖同一事务里两次范围查询看到完全一致的结果，改成 READ COMMITTED 后要重新审查语义是否符合预期。它每次一致性读取都更接近当前已提交版本，减少锁冲突的同时，也让第二次查询有机会看到别的事务刚提交的记录。

把“减少锁等待”变成可以回归的检查项

隔离级别调整不能只凭一次成功插入就验收。建议为测试准备两条连接，记录每次事务的隔离级别、SQL、锁等待时长和最终提交结果：

1. 连接 A 开启事务，执行带 FOR UPDATE 的范围读取，暂不提交。
2. 连接 B 执行范围内插入，记录是否等待以及等待多久。
3. 连接 A 分别使用 REPEATABLE READ 与 READ COMMITTED 重复测试。
4. 从 performance_schema.data_locks 与 data_lock_waits 记录锁模式、索引名和阻塞关系。
5. 把外键、重复键、唯一索引冲突和回滚路径各跑一遍，确认没有把异常吞成“没锁”。

SELECT
  ENGINE_TRANSACTION_ID,
  OBJECT_SCHEMA,
  OBJECT_NAME,
  INDEX_NAME,
  LOCK_TYPE,
  LOCK_MODE,
  LOCK_STATUS,
  LOCK_DATA
FROM performance_schema.data_locks
WHERE OBJECT_SCHEMA = DATABASE()
  AND OBJECT_NAME = 'orders';

上线时更建议把隔离级别放在明确的连接初始化逻辑或事务入口，而不是随手改服务器全局值。连接池复用会话，如果某个请求改了 SESSION 参数却没有在归还前恢复，下一条业务请求可能在完全不知情的情况下继承它。

哪些业务不适合只用 READ COMMITTED 解决

库存扣减、余额变更、优惠券领取等流程，关键不是“让读更快”，而是让条件判断和写入保持原子。可以用唯一约束配合条件更新：

UPDATE inventory
SET available = available - 1
WHERE sku = 'A-100' AND available > 0;

然后用受影响行数判断是否扣减成功。需要读取当前行再计算时，使用短事务和精确的 FOR UPDATE；需要防止重复请求时，再配合请求号唯一键。把这些业务保护都去掉，只把隔离级别换成 READ COMMITTED，反而可能让竞态更难复现。

相关问题

READ COMMITTED 会完全关闭间隙锁吗？

不会。普通范围搜索的间隙锁会减少，但外键检查、重复键检查和特定写入路径仍可能使用间隙锁，最终要看具体 SQL 与索引。

可以直接用 SET GLOBAL 改线上隔离级别吗？

不建议把实验动作直接扩大到全局。先在单个连接验证语义，再由连接池初始化逻辑明确设置，并为旧连接和回滚准备检查项。

普通 SELECT 也会锁住范围吗？

不带锁定读取的普通一致性查询通常使用 MVCC 快照；FOR UPDATE、FOR SHARE、更新和删除语句才是范围锁排查的重点。

只把事务提交得更快，能不能替代隔离级别调整？

很多时候可以明显降低等待。缩短事务、避免把网络调用放在事务内、确认索引精准命中，应该先于降低隔离级别进行。

核对资料

• MySQL 8.4 InnoDB Locking：next-key lock、gap lock 与默认隔离级别。
• MySQL 8.4 Locking Reads：FOR UPDATE 与 FOR SHARE 的锁定读取语义。
• MySQL 8.4 InnoDB Lock and Lock-Wait Information：用 Performance Schema 查看锁和等待关系。