面试记录 2026-09-17
题目：为什么 MySQL 默认使用 RR 隔离级别？
难度：medium
标签：db/mysql/concepts, mysql/isolation, difficulty/medium
评分：⭐☆☆☆（1/5）
我的回答
MySQL 默认使用 RR，也就是可重复读，这个级别是为了保证一定的效率，并且提升事务支持的能力。因为 RR 级别的事务隔离级别可以有效的处理大多数的事务问题，包括脏读、一部分类型的幻读，基本都能处理。所以它使用 RR 级别，并且它没有串行化那么高的对性能的影响，它还可以提供一定性能保证。当然如果性能要求很高，可以降低 15 个零级别，自己进行配置。
点评
优点：
- 提到 RR 解决脏读、部分幻读
- 意识到 RR 不是最严格级别，性能优于串行化
不足：
- 方向错误：RR 是一致性优先的折中，不是"效率优先"；RC 才更省锁、性能更好
- "降低 15 个零级别"表述完全错误：应该是"降低隔离级别到 RC"
- 未提核心技术原因：
- RR 通过 MVCC 实现快照读，读不阻塞写——即使一致性高也不牺牲太多性能
- RR 通过 next-key lock 大部分解决幻读，业务代码不用额外处理一致性
- 兼容 Oracle 生态：Oracle 11g 前默认也是 RR
- 未提 RC vs RR 的实际取舍：互联网团队常用 RC 是因为RR 间隙锁死锁多、锁等待长
- 未提历史背景：MySQL 5.0 之后一直默认 RR；Oracle 11g 之后默认改为 RC 是为了性能
补充：
- RR 是性能与一致性的折中，不是"性能优先"
- 大多数互联网公司生产选 RC 的原因：间隙锁死锁少、锁粒度小、并发高
- 只有强一致业务（金融、账务）才坚持 RR
完整讲解
第一部分：知识重点剖析
核心考点定位：理解 MySQL 选 RR 的技术权衡（MVCC 让 RR 也能保持高并发）与历史背景（兼容 Oracle），而不是"性能优先"。
知识点拆解：
- 四种隔离级别的性能谱系（从低到高）：
- RU：最快但完全无一致性，没人用
- RC：MVCC + 行锁，性能好、锁粒度小、并发高，但暴露不可重复读和幻读
- RR：MVCC + next-key lock，性能略低于 RC，一致性高
- Serializable：全部加锁，事务串行，性能最差
- MySQL 默认 RR 的核心原因：
- InnoDB 的 MVCC 让 RR 也能保持较高并发：快照读不加锁，即使 RR 也不牺牲读性能
- RR 通过 next-key lock 大部分解决幻读：业务代码不用手动处理一致性
- 默认更安全：宁可让业务多遇到锁，也不要让业务代码"读到不一致数据"而不自知
- 兼容 Oracle 生态：Oracle 11g 前默认也是 RR，MySQL 选择 RR 是历史延续
- 业务代码更容易写：很多 ORM 框架、事务模板默认假设 RR 行为
- 为什么不是 RC？
- RC 会暴露更多一致性问题：不可重复读、幻读都会发生，业务代码容易踩坑
- RC 下没有间隙锁，某些并发插入场景可能出现"数据错乱"
- 默认 RC 会给用户太多惊喜：不同厂商默认不一致
- 为什么不是 Serializable？
- 性能太差：所有 SELECT 都加 S 锁，并发度极低
- 死锁概率高：锁范围大，冲突多
- 几乎没人这么用：只在极小范围强一致场景才用
- 实际互联网公司为什么常用 RC？
- RR 的间隙锁死锁多：并发写入时容易相互等
- RR 锁等待时间长：next-key lock 覆盖范围大
- RC 下锁粒度小：只有行锁，冲突面小
- 业务代码能接受不可重复读：现代互联网业务（缓存、异步、最终一致）不需要严格 RR
- Oracle 11g 后也切到 RC 了：MySQL 跟随行业趋势
- 切换隔离级别的方式：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;（会话级）SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;（全局，新连接生效）START TRANSACTION ISOLATION LEVEL READ COMMITTED;（事务级）- 查看：
SELECT @@transaction_isolation;
- 实际工程建议：
- 默认保留 RR：新业务、不熟悉一致性需求的场景
- 切到 RC：高并发写入、有明确死锁问题、业务不需要严格可重复读
- 坚持 RR：金融、账务、订单等强一致场景
- 不用 Serializable：除非特殊场景
第二部分：考察方向与延伸递进
考察方向：
- 深度：能否讲清 RR 为什么在 MVCC 支撑下性能还能保持较高
- 广度：能否关联到 Oracle 默认隔离级别的历史演变
- 应用：能否针对具体业务给出 RC vs RR 的选择建议
延伸递进面试题：
- 切到 RC 后，哪些场景会出问题？
- 解答要点：跨表一致性查询、需要严格可重复读的业务逻辑、依赖间隙锁防重插入。
- RC 下并发插入同一个唯一键会不会重复？
- 解答要点：不会，因为唯一索引上的隐式锁保证唯一性，即使没有间隙锁。
- MySQL 8.0 是否推荐切 RC？
- 解答要点：官方没强制，但很多大厂 8.0 迁移时会评估 RC，配合业务改造。
第三部分：面试者参考回答（口语化）
面试官您好，MySQL 默认用 RR 隔离级别，其实是一个一致性与性能的折中选择，不是"性能优先"。
为什么不是最严格的 Serializable？ 因为 Serializable 所有 SELECT 都要加 S 锁，事务完全串行，性能太差，实际几乎没人这么用。
为什么不是更轻量的 RC？ 因为 RC 只加行锁没有间隙锁，业务代码会遇到不可重复读和幻读，很多业务逻辑依赖"事务内读到稳定数据"这个假设，切到 RC 会暴露更多一致性问题，业务代码容易踩坑。
为什么 RR 是合适的默认？ 有三个技术原因：
第一，InnoDB 的 MVCC 让 RR 也能保持高并发。RR 的快照读通过 ReadView 判断可见性，不加锁，所以读性能没损失。即使是 RR，普通 SELECT 也是并发执行的。
第二，RR 通过 next-key lock 大部分解决了幻读。虽然 RR 并不能完全消除幻读（快照读+当前读混用仍可能遇到），但业务代码写起来不用手动处理一致性，默认更安全。
第三，兼容 Oracle 生态。Oracle 11g 之前默认也是 RR，MySQL 选择 RR 是历史延续。很多传统业务迁移过来时不需要改隔离级别。
但实际互联网公司很多切到 RC，这是另一回事：
- RR 的间隙锁死锁多：并发写入时容易相互等待
- RR 的 next-key lock 覆盖范围大：锁等待时间长
- RC 锁粒度小并发高：只有行锁，冲突面小
- 现代互联网业务能接受不可重复读：缓存、异步、最终一致，不需要严格 RR
- Oracle 11g 之后也切到 RC 了：行业趋势
所以我的建议是：默认保留 RR，遇到死锁或锁等待问题再切 RC，前提是业务代码不依赖严格可重复读。切 RC 之前要评估有没有跨表一致性查询、有没有依赖间隙锁防重插入的逻辑。金融账务这类强一致业务还是保持 RR。
https://chat.deepseek.com/share/ua60jdf5y3m2my00j5