MySQL 事务隔离级别改成 READ COMMITTED 后会少什么锁

把 InnoDB 的隔离级别从默认的 REPEATABLE READ 改成 READ COMMITTED 后，真正“少掉”的主要不是所有行锁，而是范围扫描时用于保护间隙的 gap lock 和由它组成的 next-key lock。同时，UPDATE、DELETE 在判断 WHERE 条件后，会释放不匹配行的记录锁。

但普通 SELECT 本来就是非锁定读，切换后它的核心变化是同一事务内每次一致性读都取得自己的新快照；SELECT ... FOR UPDATE、FOR SHARE 仍然是锁定读。下面按读类型和 DML 类型拆开看，排查“改了隔离级别却还在等锁”会更准确。

先把快照读和锁定读分开

普通 SELECT 在 InnoDB 中属于一致性非锁定读，不会为访问的表设置锁。REPEATABLE READ 会在事务第一次一致性读时建立快照，后续普通查询继续看这份快照；READ COMMITTED 则让每次一致性读使用新的快照，所以第二次查询可能看到别的事务刚提交的数据。

这并不意味着 READ COMMITTED 让查询“完全不受并发影响”。如果业务需要读取后马上修改，通常会写成锁定读；这时查询目的从“看一个快照”变成“读取并占用可修改的记录”。隔离级别降低的是范围保护，不是显式锁定读的存在。

少的是范围间隙锁，不是记录锁

在默认的 REPEATABLE READ 下，对非唯一索引范围执行锁定读、UPDATE 或 DELETE 时，InnoDB 可能使用 gap lock 或 next-key lock，阻止其他事务把新记录插入扫描范围。改成 READ COMMITTED 后，这类语句通常只锁索引记录，不锁记录前面的间隙，因此范围旁边可以插入新行，幻读风险也随之回来了。

因此，观察锁等待时要先看访问路径：是唯一索引等值、非唯一索引范围，还是没有合适索引而扫描隐藏聚簇索引。只看“隔离级别已改成 READ COMMITTED”这一行配置，无法推出具体锁集合。

UPDATE 和 DELETE 会释放哪些记录锁

对 UPDATE 或 DELETE，InnoDB 在读取候选行时会先取得排他记录锁，再由 MySQL 判断 WHERE 是否匹配。在 READ COMMITTED 下，不匹配的记录锁会在判断后释放；真正更新或删除的行继续持有记录锁直到事务结束。这就是批量条件更新更容易减少无效锁占用的地方。

如果目标行已被其他事务锁住，UPDATE 还可能进行 semi-consistent read：先把最新已提交版本交给 MySQL 判断条件。条件不匹配就不必继续等待修改；条件匹配则重新读取并等待或取得锁。它能降低一部分无效等待和死锁概率，但不能保证没有死锁，也不能替代合理索引。

切换前后的排查清单

建议先在单个会话验证，不要直接把全局默认值当成修复动作。单事务设置可以这样写：

-- 只影响本次事务，验证完成后由 COMMIT/ROLLBACK 结束
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;

-- 普通 SELECT 取一致性快照，不主动锁住读取行
SELECT id, status FROM orders WHERE customer_id = 42;

-- 需要读取后修改时显式使用锁定读
SELECT id, status FROM orders WHERE id = 1001 FOR UPDATE;
COMMIT;

验证时重点记录四件事：查询是否走了预期索引；条件是等值还是范围；语句是不是显式锁定读；表上是否存在外键或唯一约束检查。若仍有锁等待，再查看事务持有的记录范围和等待对象，不要只把问题归咎于隔离级别。

常见问题

READ COMMITTED 会不会完全取消 gap lock？

不会。普通范围保护被放宽，但外键约束检查和重复键检查仍可能使用 gap lock。

改成 READ COMMITTED 后，普通 SELECT 会加记录锁吗？

不会。普通一致性读仍是非锁定读；需要锁住记录时使用 FOR UPDATE 或 FOR SHARE。

为什么改了隔离级别还会死锁？

READ COMMITTED 只减少部分范围锁和无效记录锁，多个事务仍可能以不同顺序争用相同记录、索引或约束检查资源。