MySQL 事务隔离级别：RC 还是 RR？8 年 DBA 视角下我最纠结的一个默认值

背景： 做 DBA 这 8 年，我接手过的 MySQL 实例里，大约 60% 跑在默认的 REPEATABLE READ（RR），40% 被业务方或前任 DBA 调成了 READ COMMITTED（RC）。每次新团队来问我"隔离级别该用哪个"，我都想说：这取决于你的业务到底需不需要那个"可重复读"的语义——但现实是，90% 的业务其实根本不需要，只是没人敢改，因为"MySQL 默认就是 RR，改 RC 是不是不安全？"

常见分歧（我观察到的三种阵营）：

1）RR 党（MySQL 默认信仰）：

• "MySQL 默认 RR，不改就是最安全的"；
• 报表 / 对账 / 批处理场景下，RR 的一致性快照（同一事务内多次读同一行结果一致）确实省心；
• 幻读在 RC 下确实存在（虽然 InnoDB RR 也只是"缓解"而非"消除"幻读，很多人没分清这层）。

2）RC 党（Oracle / PG 迁移经验）：

• 从 Oracle（默认 RC）迁过来的团队，业务代码里根本没写 RR 级别的逻辑，切回 RC 后死锁率直降 40%+（gap lock 和 next-key lock 在 RC 下大幅减少）；
• undo log 更短 → purge 压力小 → history list length 不会飙到几十万（我上周刚处理了一个 history list 破 128 万的工单，根因就是一条 6 小时长事务在 RR 下把 undo 全钉住了）；
• 并发写场景下，RC 的锁粒度更细（只锁记录，不锁间隙），死锁概率显著低于 RR。

3）折中党（全局 RC + 显式锁）：

• 全局用 RC 降低锁竞争和 undo 压力；
• 少数真正需要"一致性读"的事务（如资金对账、库存扣减），用 SELECT ... FOR UPDATE 或显式加锁来保证；
• 代价：业务侧必须建立"显式锁"的文化，写代码的人得清楚哪些行需要锁住、哪些不需要——对团队要求更高。

我的倾向（供拍砖）： 作为 DBA，我倾向全局 RC + 关键路径显式锁。理由很朴素：

• 运维侧：RC 下 undo 短、purge 轻、gap lock 少 → 死锁告警少、history list 不会失控、磁盘 IO 更平稳；
• 性能侧：高并发写场景（订单、库存、支付），RC 的锁竞争窗口比 RR 小一个量级；
• 一致性侧：真正需要"快照一致"的场景（对账、报表），业务侧用显式锁或独立只读副本更可控，而不是靠 RR 的 MVCC 快照"兜底"。

但我也承认 RC 不是万能的：如果你的业务代码里大量依赖"同一事务内两次 SELECT 结果一致"（且没有显式锁），贸然切 RC 会引入幻读 bug。所以切之前必须做全量回归。

想听大家聊： a）你们线上跑的是 RC 还是 RR？当初为什么这么定？有没有中途切换过？切换后遇到了什么坑（或爽到什么程度）？ b）你们有没有"全局 RC + 个别事务 RR"的混合做法？MySQL 支持 session 级 SET TRANSACTION ISOLATION LEVEL，你们怎么管理的？ c）如果业务方坚持"MySQL 默认就是 RR，别动"，你作为 DBA 怎么劝？需要给什么数据才有说服力？ d）有没有人踩过"切了 RC 之后某个报表数据突然不对"的坑？根因是什么？

欢迎带具体场景和数据来聊，纯理论派也欢迎——我准备了一堆 EXPLAIN 和锁监控截图随时上。