MySQL 8.0默认仍是RR，主因是向后兼容老系统和中间件；RR在事务首次SELECT时建ReadView并复用，RC则每次SELECT新建，RR易致undo log膨胀、purge延迟，且其幻读防护依赖索引覆盖，非绝对可靠。
MySQL 8.0 默认仍是 RR，不是因为“更安全”或“更适合业务”，而是为了向后兼容老系统和中间件——尤其是那些依赖 RR 下 MVCC 快照时机、Next-Key Lock 行为、甚至 binlog 语义的组件。
RR 的 ReadView 创建时机在事务中实际是“第一次 SELECT 时”
很多人误以为 RR 在 BEGIN 就建快照，其实不是：InnoDB 直到事务内第一次执行 SELECT（非锁定读）才生成 ReadView，之后所有一致性读都复用它。而 RC 是每次 SELECT 都新建 ReadView。
这意味着：
- RR 下长事务可能长期持有旧版本，拖慢
purge线程，导致undo log膨胀、历史版本链变长 - 某些 ORM（如早期 MyBatis + Spring Transaction）隐式依赖“事务内多次查询结果一致”，换成 RC 后逻辑可能出错
- ShardingSphere 等分库中间件在解析 SQL 时，会根据隔离级别推断锁行为；RR 的间隙锁语义被部分路由策略当作前提
ROW 格式 binlog 已普及，但 RR 的锁机制仍被当“默认契约”
MySQL 5.1+ 支持 binlog_format=ROW，它记录行变更而非 SQL 文本，从根源上消除了 RC + STATEMENT 导致主从不一致的风险。按理说，RC + ROW 完全可替代 RR。
但现实是：
- 大量存量业务部署在未显式配置
binlog_format的实例上，默认仍是MIXED或遗留STATEMENT，RR 成了兜底保险 - DBA 运维脚本、备份工具（如 mydumper）、审计插件常假设“RR 下写操作会被间隙锁阻塞”，换 RC 后可能漏掉并发冲突预警
- 监控指标如
Innodb_row_lock_time_avg的基线值，是基于 RR 下锁竞争强度建立的；切 RC 后数值骤降，反而触发误告警
幻读在 RR 下并未真正“被解决”，只是被 Next-Key Lock 压制了部分场景
RR 声称防止幻读，但实验表明：只要插入语句不命中索引（比如 WHERE b = 1，而 b 列无索引），InnoDB 就不会加间隙锁，Session2 仍可成功插入新行，Session1 再查就会看到“多出来”的数据——这就是幻读。
所以：
- RR 的幻读防护是有条件的：必须走索引，且索引能覆盖查询条件
- 业务若依赖“绝对无幻读”，仍需手动加
SELECT ... FOR UPDATE或应用层重试逻辑 - 大厂改 RC 并非放弃一致性，而是把“避免幻读”的责任交给更可控的地方：唯一约束、应用幂等、或者最终一致性校验
真正容易被忽略的是：RR 的“强一致性假象”会让开发者低估并发风险，而它的锁开销和版本膨胀在高吞吐 OLTP 场景中早已成为瓶颈。切换前不评估 MVCC 压力、不检查中间件兼容性、不验证索引覆盖度，只改一个 transaction_isolation 配置，大概率会出问题。
