MySQL事务隔离级别RC与RR模式在生产环境差异如何对比，哪个更合适？

本文共计1019个文字，预计阅读时间需要5分钟。

MySQL 默认使用 REPEATABLE READ，但在高并发系统中（尤其是高并发互联网服务），系统会主动切换到 READ COMMITTED。这不是配置错误，而是基于权限锁、MVCC、快照机制和binlog兼容性后的主动选择。

为什么 RR 在 MySQL 中默认却常被替换

RR 是 MySQL 历史原因定的默认值：早期主从复制依赖 STATEMENT 格式的 binlog，而 READ COMMITTED 在该格式下有数据不一致风险。如今 ROW 格式已成标配，这个限制早已解除。

但 RR 的实际代价在高并发写场景里很实在：

• REPEATABLE READ 默认启用 Next-Key Lock（记录锁 + 间隙锁），哪怕你只查主键，InnoDB 也可能锁住索引间隙，导致无关插入被阻塞
• 一个 SELECT ... WHERE status = 'pending'（无索引）可能触发全表扫描+全表间隙锁，直接卡住其他事务的 INSERT
• READ COMMITTED 只用 Record Lock，锁更轻、范围更确定，冲突概率显著下降

RC 和 RR 的一致性读行为差异直接影响业务逻辑

关键区别不在“能不能读到新数据”，而在“什么时候生成快照”：

• READ COMMITTED：每次 SELECT 都生成新 ReadView，读到的是语句执行时刻最新已提交的数据
• REPEATABLE READ：第一次 SELECT 时生成 ReadView，后续所有查询都复用它，即使其他事务已提交修改，本事务也看不到

这意味着：

• 如果你在事务里先查库存，再查价格，最后扣减——用 RR 能保证两次读之间数据“静止”，但可能基于过期价格做决策
• 用 RC 则每次读都是“最新快照”，更适合报表类、状态展示类接口，但要接受同一事务内两次 SELECT 结果可能不同

幻读在 RR 和 RC 下的表现并不像文档写的那么绝对

SQL 标准说 RR 不解决幻读，但 InnoDB 的 RR 实际通过 Next-Key Lock 抑制了大部分幻读场景（尤其是带范围条件的 SELECT）。而 RC 因为不用间隙锁，幻读更容易发生——但这是否构成问题，得看 SQL 是否真有范围条件：

• SELECT * FROM orders WHERE user_id = 123（有索引）→ RC 下基本不幻读，RR 下锁更重
• SELECT * FROM logs WHERE created_at > '2026-04-01'（范围+无索引）→ RC 下极易幻读，RR 下会锁住时间范围间隙

真正要警惕的不是“有没有幻读”，而是“你的业务是否依赖两次范围查询结果稳定”。如果只是分页查列表，幻读通常可容忍；如果是“先查总数再删超限记录”，就必须锁或改逻辑。

切换隔离级别前必须验证的三件事

别只改 transaction_isolation 参数就上线：

• 确认 binlog_format 是 ROW 或 MIXED，否则 READ COMMITTED 可能引发主从延迟或不一致
• 检查所有 UPDATE/DELETE 语句是否都命中索引，RC 下没间隙锁兜底，全表扫描等于给整张表加 X 锁
• 用慢日志或 INFORMATION_SCHEMA.INNODB_TRX 观察当前锁等待情况，RR 切 RC 后若发现大量 lock wait timeout 消失，说明原来锁争抢就是瓶颈

最常被忽略的一点：Spring 的 @Transactional(isolation = Isolation.REPEATABLE_READ) 会覆盖全局设置，代码层显式指定的隔离级别优先级高于数据库配置。