互联网高并发场景下，RC与RR的选型真相
先说一个核心结论：在互联网高并发场景下，RC（Read Committed）比RR（Repeatable Read）更常用，且已成为多数主流业务系统（如电商订单、支付、即时通讯）默认或主动切换的选择。
为什么RC在互联网场景中实际更“稳”？
RR隔离级别提供的“可重复读”，其原理是在事务启动时拍下数据快照。这个机制听起来很安全，但在长事务与高频更新的双重压力下，反而容易成为系统稳定性的隐患。
具体来说，RR会带来几个典型问题：
SELECT操作无法看到其他事务已提交的最新数据，这可能导致业务逻辑误判。一个经典的例子是库存校验：如果读取的是旧值，就极易引发超卖。- 长事务会持续持有
read view，从而阻塞purge线程。其后果是undo log无法及时清理，最终导致系统表空间ibdata1持续膨胀。 - 为了解决幻读问题，RR级别会启用间隙锁（Gap Lock）。这把锁的范围很大，在写密集的场景中，锁冲突会显著增多，极易引发死锁或导致
Lock wait timeout exceeded这类错误。
反观RC级别，它每次执行 SELECT 都会读取最新已提交的数据版本。这种机制看似“不稳定”，但恰恰因为其行为简单、锁竞争更少，再配合应用层的重试与幂等设计，整个系统的行为反而更可控、更轻量。
RR到底适合什么场景？
需要明确的是，RR并非“过时”的技术，只是它的适用面相对较窄。它真正能发挥价值的场景非常明确：
- 报表与对账类业务：这类业务需要事务内多次查询的结果严格一致（例如财务对账），且通常查询不频繁、事务周期短、没有高频更新干扰。
- 迁移或兼容老系统：从Oracle或PostgreSQL迁移至MySQL时，用户可能出于习惯选择RR，但往往没有充分意识到其在MySQL中可能带来的性能代价。
- 特定历史环境：在未开启
binlog_format = ROW的主从复制环境中，RR配合STATEMENT格式能在一定程度上避免复制不一致。不过，这种组合本身已不被推荐。
这里提一个历史细节：在MySQL 5.6及更早版本中，参数 innodb_locks_unsafe_for_binlog = ON 曾让RC的表现接近RR。但该参数现已被移除，如今RC的行为就是标准定义。
切换到RC的实操注意事项
将隔离级别从RR切换到RC，绝非修改一个数据库参数那么简单。真正的关键在于应用层的协同改造，有几个点必须警惕：
- 确认业务容忍度：必须确保业务逻辑能接受“非可重复读”现象。例如，用户刷新余额页面，第一次看到增加了100元，第二次刷新却显示增加了200元，这在RC下是完全合法且正常的。
- 精细化更新条件：所有
UPDATE ... WHERE语句必须携带足够精确的条件（最好包含唯一键或版本号），避免因为WHERE条件读到旧值而导致错误的更新。 - 重构“先查后更”逻辑：应尽量避免在RC下使用“先SELECT查询，再根据结果UPDATE”的模式。取而代之的，是使用类似
UPDATE ... WHERE id = ? AND status = 'pending'的原子操作来完成判断与更新。 - 加强监控：需要重点关注
Innodb_row_lock_waits指标，并检查慢查询日志中是否出现Waiting for table metadata lock的语句。因为RC下的锁竞争模式发生了变化，一些原本运行良好的SQL可能会突然变慢。
MySQL 8.0+的一个隐藏影响
这里有一个容易被忽略的细节：MySQL 8.0默认的隔离级别确实是 REPEATABLE-READ。但是，如果你同时使用了 binlog_format = ROW 和 sla ve_parallel_type = LOGICAL_CLOCK（即基于逻辑时钟的并行复制），那么从库在回放二进制日志时，其隔离效果会更接近RC的语义。
这意味着什么？意味着即使主库设置为RR，从库在应用日志时也可能“看不见”某些中间状态，从而导致主从之间出现短暂的数据不一致。这种由底层机制造成的隐式差异，比显式地将隔离级别切换为RC更难排查和定位。
话说回来，技术选型真正的挑战，从来不是简单地选择RC或RR。关键在于，整个调用链路——包括应用代码、连接池配置、ORM框架以及各类中间件——是否对所选隔离级别的行为有统一、清晰的认知，并具备相应的兜底处理能力。举个例子，即使用数据库是RC级别，如果MyBatis的 @Select 方法结果被缓存了，应用层仍然可能“固执地”返回旧数据。这才是架构设计中更需要通盘考虑的问题。
