本页内容受版权保护 · 已添加水印 · 禁止任何形式转载
事务与并发（ACID / 隔离级别 / 锁 / MVCC） · ACID 与隔离级别

MySQL InnoDB 的默认隔离级别是 RR，为什么不是 RC？

Why is the default isolation level for MySQL InnoDB RR, and not RC?

答案语言

考察要点

这道题面试官想看你是否深刻理解了 MySQL 的事务隔离级别，特别是 Repeatable Read (RR) 和 Read Committed (RC) 的核心差异。更进一步，是考察你是否知道这一设计决策背后的历史原因和工程考量，即 MySQL 主从复制（Replication）机制与 binlog 的紧密关系。回答此题能体现你对数据库底层原理的掌握深度。

核心概念

要回答这个问题，必须先厘清以下几个核心概念：

1. 事务隔离级别

SQL 标准定义了四种隔离级别，以解决并发事务中可能出现的脏读、不可重复读、幻读问题。

隔离级别脏读 (Dirty Read)不可重复读 (Non-Repeatable Read)幻读 (Phantom Read)
读未提交 (Read Uncommitted)可能可能可能
读已提交 (Read Committed)不允许可能可能
可重复读 (Repeatable Read)不允许不允许基本不允许
串行化 (Serializable)不允许不允许不允许
  • 不可重复读：同一事务内，两次读取同一行数据，得到的结果不同。通常是由于其他事务对该行进行了 UPDATE 或 DELETE。
  • 幻读：同一事务内，两次执行相同范围查询，第二次查询返回了第一次查询未出现的新行。通常是由于其他事务 INSERT 了符合条件的新数据。

2. RC 与 RR 的 MVCC 实现差异

InnoDB 使用多版本并发控制（MVCC）来实现 RC 和 RR 隔离级别，核心在于 Read View（读视图） 的创建时机不同。

  • Read Committed (RC)：事务中的每条 SELECT 语句执行前，都会创建一个新的 Read View。这保证了每次查询都能读到已经提交的最新数据。
  • Repeatable Read (RR)：事务中的第一条 SELECT 语句执行时创建一个 Read View，后续的所有 SELECT 都复用这个 Read View。这保证了在整个事务期间，看到的数据版本是一致的，仿佛时间被冻结在了事务开始的那一刻。

示例： 假设有表 products，初始数据为 {id: 1, stock: 10}。

时间事务 A (RR 或 RC)事务 B (已提交)
T1BEGIN;
T2SELECT stock FROM products WHERE id = 1; (结果: 10)
T3UPDATE products SET stock = 8 WHERE id = 1; COMMIT;
T4SELECT stock FROM products WHERE id = 1;
RC 下结果: 8 (新建 Read View，读到 T3 的已提交修改)
RR 下结果: 10 (复用 T2 的 Read View，看不到 T3 的修改)

3. Binlog (二进制日志) 与主从复制

binlog 是 MySQL Server 层的日志，记录了所有对数据库进行更改的 SQL 语句（或行数据），主要用于数据恢复和主从复制。

binlog 有三种格式：

  1. STATEMENT: 记录原始的 SQL 语句。优点是日志文件小，缺点是在某些情况下可能导致主从数据不一致（例如，UPDATE ... LIMIT 1，在主库和从库上可能更新了不同的行）。
  2. ROW: 记录每一行数据的变更细节。优点是能精确复制，不会出现不一致，缺点是日志文件较大。
  3. MIXED: 混合模式，MySQL 会根据 SQL 语句自动选择使用 STATEMENT 或 ROW 格式。

4. 核心原因：保证主从复制的正确性

MySQL 在早期版本（5.0 之前）以及后续很长一段时间内，默认的 binlog 格式是 STATEMENT。

问题场景：如果 MySQL 默认隔离级别是 RC，并且 binlog 格式为 STATEMENT，主从复制会出问题。

假设主库（Master）隔离级别为 RC，从库（Slave）也为 RC。 表结构与数据：

sql
 1CREATE TABLE t (id INT PRIMARY KEY, name VARCHAR(20));
 2INSERT INTO t VALUES (10, 'a'), (30, 'c');
时间主库 - 事务 A主库 - 事务 B从库（SQL 线程）
T1BEGIN;
T2DELETE FROM t WHERE id > 20; (删除了 id=30 的行)
T3BEGIN;
T4INSERT INTO t VALUES (25, 'b');
T5COMMIT;
T6COMMIT;
T7接收到 T2 的 binlog: DELETE FROM t WHERE id > 20;
T8接收到 T5 的 binlog: INSERT INTO t VALUES (25, 'b');

在主库上，事务 A (T2) 看不到事务 B (T4) 插入的数据，所以 DELETE 语句只删除了 id=30 的行。 但是，binlog 记录的是语句的提交顺序。事务 B 先提交，所以 INSERT 的日志在 DELETE 的日志之前。

从库在回放 binlog 时：

  1. 先执行 INSERT INTO t VALUES (25, 'b');。此时从库的表数据为 {10, 'a'}, {25, 'b'}, {30, 'c'}。
  2. 再执行 DELETE FROM t WHERE id > 20;。这条语句会删除 id=25 和 id=30 两行。

最终结果：

  • 主库：剩下 {10, 'a'}
  • 从库：剩下 {10, 'a'}
  • 等等，这个例子好像没问题？ 不，让我们换一个更经典的 UPDATE 例子。

更经典的幻读导致主从不一致场景（RC 隔离级别 + STATEMENT 格式）

时间主库 - 事务 A主库 - 事务 B
T1BEGIN;
T2UPDATE t SET name = 'x' WHERE id > 15; (此时符合条件的只有 id=30, 1 行受影响)
T3BEGIN;
T4INSERT INTO t VALUES (20, 'new');
T5COMMIT;
T6COMMIT;

在主库上，事务 A 的 UPDATE 只影响了 id=30 这一行。 binlog 中记录了 UPDATE 和 INSERT 两个操作。如果 INSERT 先提交，UPDATE 后提交，在从库回放时：

  1. INSERT INTO t VALUES (20, 'new');
  2. UPDATE t SET name = 'x' WHERE id > 15; 在从库执行 UPDATE 时，会匹配到 id=20 和 id=30 两行，导致 2 行数据被更新。主从数据不一致就此产生！

解决方案： 将隔离级别设为 RR。在 RR 级别下，事务 A 在 T2 执行 UPDATE 时，由于 MVCC 和间隙锁（Gap Lock）的存在，事务 B 的 INSERT (T4) 会被阻塞，直到事务 A 提交。这样保证了事务 A 在执行期间，查询范围内的记录集是稳定的，UPDATE 语句在主库和从库上影响的行数必然一致。

结论：MySQL 将 RR 作为默认隔离级别，主要是为了在 binlog 格式为 STATEMENT 时，保证主从复制的可靠性和数据一致性。

常见低分回答

  1. “因为 RR 比 RC 更安全，能防止幻读，所以是默认的。”
    • 这个回答过于肤浅，只说了现象，没有解释为什么 MySQL 特别需要 防止幻读，忽略了背后最关键的 binlog 和主从复制机制。
  2. “RR 性能更好。”
    • 这是完全错误的。通常情况下，RC 的锁粒度更小（没有或很少有间隙锁），并发性能优于 RR。RR 可能会因为间隙锁导致更多的锁等待和死锁。
  3. 混淆不可重复读和幻读。
    • 无法清晰地区分“某一行数据变了”和“多出来几行新数据”这两种场景，导致论证混乱。
  4. “RR 用 MVCC 彻底解决了幻读。”
    • 这个说法不完全准确。对于普通 SELECT，MVCC 的确通过 Read View 避免了幻读。但对于 SELECT ... FOR UPDATE 或 UPDATE/DELETE 这类当前读，MVCC 不起作用，InnoDB 需要借助 Next-Key Lock (Record Lock + Gap Lock) 来真正“锁住”范围，防止幻读的发生。

工程实践与优化

  • 默认不等于最优：虽然 MySQL 默认是 RR，但在现代互联网应用中，绝大多数业务场景都可以安全地运行在 RC 隔离级别下。像阿里、字节等大厂内部，通常会将数据库的默认隔离级别全局修改为 RC。
  • 为什么可以换成 RC：
    1. binlog 格式的演进：从 MySQL 5.7 开始，binlog_format 的默认值已经是 ROW。ROW 格式记录的是行的变更，而不是 SQL 语句，因此天然避免了 STATEMENT 格式下因执行上下文不同而导致的主从不一致问题。
    2. 性能收益：RC 级别下，没有间隙锁（或极少使用），大大减少了并发事务间的锁冲突和死锁概率，能显著提升系统的并发处理能力（TPS）。
    3. 业务容忍度：大多数业务逻辑并不强依赖于“可重复读”的特性。即使出现幻读，也可以通过应用层的逻辑（如加锁、重试）来保证最终一致性。
  • 如何选择：
    • 如果你的业务需要在一个事务中多次查询同一范围并要求结果集绝对不变，或者你在使用 STATEMENT 格式的 binlog，那么坚持使用 RR。
    • 对于绝大多数高并发的 Web 应用，推荐使用 RC，以获得更好的并发性能。可以通过 SET GLOBAL transaction_isolation = 'READ-COMMITTED'; 来修改。

常见追问与延伸题目

  1. 追问：既然现在 binlog 默认是 ROW 格式，为什么 MySQL 官方还不把默认隔离级别改成 RC？

    • 回答要点 1 (向后兼容性)：MySQL 作为一个广泛使用的基础软件，稳定性与向后兼容性是首要考虑的。无数现存的系统、应用和运维脚本都是基于 RR 这个默认值来设计和运行的。贸然修改默认值会带来巨大的兼容性风险，可能导致大量老系统出现非预期的行为。
    • 回答要点 2 (用户选择权)：MySQL 提供了修改隔离级别的选项，将选择权交给了用户。有经验的 DBA 或架构师会根据自己的业务场景选择最合适的隔离级别。保持 RR 作为默认值，是一种“保守且安全”的策略。

  2. 追问：RR 是如何通过锁机制来避免幻读的？

    • 回答要点 1 (MVCC vs 锁)：首先要区分两种读：快照读（SELECT）和当前读（SELECT ... FOR UPDATE/LOCK IN SHARE MODE, INSERT, UPDATE, DELETE）。快照读通过 MVCC 避免幻读。当前读则需要依赖锁。
    • 回答要点 2 (Next-Key Lock)：InnoDB 在 RR 级别下，对当前读操作会使用 Next-Key Lock。它由两部分组成：Record Lock (行锁) 和 Gap Lock (间隙锁)。行锁锁住已存在的记录，间隙锁锁住记录之间的“空隙”，防止其他事务在这个空隙中插入新记录。例如，WHERE id > 10 会锁住 id=10 之后的所有记录，以及 id=10 到下一条记录之间的间隙，直到无穷大。这样就彻底杜绝了其他事务插入 id > 10 的新行，从而避免了幻读。

  3. 追问：如果我把隔离级别从 RR 降到 RC，需要注意哪些潜在的风险？

    • 回答要点 1 (幻读问题)：最直接的风险就是幻读。需要审视业务代码，判断是否存在“先 SELECT 检查，后 INSERT/UPDATE”的逻辑。例如，先 SELECT COUNT(...) 检查某个条件下是否有数据，如果没有就 INSERT。在 RC 下，这个逻辑可能因为并发 INSERT 而出错。需要通过 SELECT ... FOR UPDATE 或其他锁机制来保证原子性。
    • 回答要点 2 (主从复制)：虽然 ROW 格式解决了数据不一致问题，但有一种特殊情况：如果事务中混合了 DDL 和 DML，并且依赖于 RR 的特性，降级到 RC 可能会产生问题。但这属于非常边缘的场景。
    • 回答要点 3 (应用逻辑依赖)：检查应用代码是否无意中依赖了“可重复读”的特性。例如，一个长事务中，多次读取同一个配置或状态，并期望它保持不变。在 RC 下，这个值可能会在事务执行过程中被其他已提交的事务所改变，导致业务逻辑错误。
← Previous
SQL 标准的四种隔离级别？各自能解决什么问题？
Next →
RR（可重复读）是否解决了幻读？InnoDB 是怎么用 next-key lock 处理幻读的？