SQL 标准的四种隔离级别？各自能解决什么问题？

考察要点

这道题考察的是候选人对数据库事务并发控制核心理论的理解。面试官想看你是否清晰地掌握：

1. 并发事务带来的三大问题：脏读（Dirty Read）、不可重复读（Non-Repeatable Read）、幻读（Phantom Read）。
2. SQL 标准定义的四种隔离级别：以及它们分别是为了解决上述哪些问题而设计的。
3. 隔离级别与性能的权衡：理解更高级别的隔离虽然能保证数据一致性，但会牺牲并发性能。

核心概念

数据库事务并发执行时，若不加控制，可能导致数据不一致。SQL 标准定义了四种隔离级别来应对这些问题，其核心是解决以下三种现象：

1. 脏读 (Dirty Read) 一个事务（T1）读取了另一个事务（T2）尚未提交的数据。如果 T2 最终回滚，那么 T1 读取到的就是“脏”数据。

2. 不可重复读 (Non-Repeatable Read) 一个事务（T1）内，多次读取同一行数据，但结果不同。这是因为在 T1 读取期间，另一个事务（T2）修改了这行数据并提交了。

   • 侧重点：对同一行数据的 UPDATE 操作。

3. 幻读 (Phantom Read) 一个事务（T1）内，多次执行相同的范围查询，但返回的结果集行数不同。这是因为在 T1 查询期间，另一个事务（T2）INSERT 或 DELETE 了满足该范围条件的行并提交了。

   • 侧重点：对一个范围的 INSERT / DELETE 操作，导致行数变化。

四种隔离级别详解

1. 读未提交 (Read Uncommitted)

• 定义：一个事务可以读取到其他事务未提交的数据。
• 解决的问题：无。这是最低的隔离级别，几乎不提供任何隔离保证。
• 实现：通常不对读操作加锁，性能最高，但数据一致性最差。生产环境基本不用。

2. 读已提交 (Read Committed, RC)

• 定义：一个事务只能读取到其他事务已经提交的数据。
• 解决的问题：解决了脏读。
• 实现机制 (以 InnoDB 为例)：通过 MVCC (Multi-Version Concurrency Control) 实现。每次 SELECT 语句执行时，都会创建一个新的读视图 (Read View)，只能看到在该时间点前已经提交的事务所做的修改。这被称为“语句级快照”。
• 存在的问题：在一个事务内，两次相同的查询之间，若有其他事务提交了更新，会导致不可重复读。

3. 可重复读 (Repeatable Read, RR)

• 定义：在一个事务开始后，无论其他事务如何修改并提交数据，该事务内多次读取同一行数据的结果都是一致的。
• 解决的问题：解决了脏读和不可重复读。
• 实现机制 (以 InnoDB 为例)：同样基于 MVCC。不同的是，它在事务开始时创建读视图 (Read View)，整个事务期间都使用这个读视图。这被称为“事务级快照”。
• 关于幻读的特殊说明：
  • SQL 标准：标准的 RR 级别是无法解决幻读的。
  • MySQL InnoDB：InnoDB 在 RR 级别下，通过 MVCC + Next-Key Locking (间隙锁+行锁) 机制，在很大程度上解决了幻读问题。
    • 对于普通 SELECT，MVCC 保证了事务开始时的快照，不会看到新插入的行。
    • 对于 SELECT ... FOR UPDATE 或 UPDATE/DELETE 等当前读，会使用 Next-Key Lock 锁住一个范围，防止其他事务在这个范围内插入数据。

4. 串行化 (Serializable)

• 定义：强制事务串行执行，一个事务执行完毕后，另一个事务才能开始。
• 解决的问题：解决了脏读、不可重复读、幻读所有并发问题。
• 实现机制：通常通过对所有读写操作都加锁（如读锁、写锁）来实现，例如将所有 SELECT 语句隐式地转换为 SELECT ... FOR SHARE (MySQL 8.0)。
• 缺点：并发性能极差，因为事务需要排队等待。一般只在对数据一致性要求极高且并发量不大的场景下使用。

常见低分回答

1. 混淆“不可重复读”和“幻读”：错误地将两者都描述为“读到了不一样的结果”，而没有说清前者是针对单行记录的 UPDATE，后者是针对一个范围的 INSERT/DELETE。
2. 绝对化地回答“MySQL 的 RR 级别解决了幻读”：这是一个常见的“知其然不知其所以然”的回答。高分回答应指出，这是 InnoDB 引擎通过 MVCC 和 Next-Key Lock 额外实现的，并非 SQL 标准 RR 的要求，并且要能区分快照读和当前读在幻读场景下的不同表现。
3. 不知道主流数据库的默认隔离级别：当被问到“MySQL 默认是什么级别？”时回答“读已提交”，会暴露实践经验的不足。正确答案是 MySQL (InnoDB) 默认为可重复读 (RR)，而 Oracle、PostgreSQL 等默认为读已提交 (RC)。
4. 认为隔离级别越高越好：忽略了隔离级别是性能和一致性之间的权衡。在面试中直接说“应该用串行化来保证绝对安全”是典型的学院派回答，缺乏工程思维。
5. 对实现机制含糊其辞：只说“通过加锁实现”，而不提 MVCC，或者无法解释 Read View、Undo Log、Next-Key Lock 等关键概念，说明理解深度不够。

工程实践与优化

• 选择合适的隔离级别：绝大多数互联网应用场景（90%以上）使用读已提交 (Read Committed) 即可满足需求，并能获得较好的并发性能。RC 级别下，锁的持有时间更短，能有效减少锁冲突。
• MySQL 为何默认 RR：这与早期的主从复制机制有关。当 binlog_format 为 STATEMENT 时，为了保证主从数据一致性，必须使用 RR 级别。现在 binlog_format 默认为 ROW，这种依赖性已经大大降低。很多公司会将新业务的 MySQL 默认隔离级别调整为 Read Committed。
• 查看与设置隔离级别：
  sql

  ⧉⛶

   1-- 查看当前会话的隔离级别
   2SELECT @@transaction_isolation;
   3-- 查看全局隔离级别
   4SELECT @@global.transaction_isolation;
   5
   6-- 设置当前会话的隔离级别
   7SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
   8-- 设置全局隔离级别（新连接生效）
   9SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

• 使用显式锁或乐观锁：对于某些需要“可重复读”或防止更新丢失的特定业务逻辑，不一定非要提升整个事务的隔离级别。可以在 RC 级别下，通过 SELECT ... FOR UPDATE (悲观锁) 或增加 version 字段 (乐观锁) 来进行更细粒度的并发控制，对系统整体性能影响更小。

常见追问与延伸题目

1. 追问：你刚才提到了 MVCC，能详细讲讲它在 InnoDB 中是如何工作的吗？

   • 回答要点：MVCC 的核心是“版本链”和“读视图”。
     • 版本链 (Version Chain)：InnoDB 表的聚簇索引记录中包含两个隐藏列：DB_TRX_ID (创建或最后修改该版本的事务ID) 和 DB_ROLL_PTR (指向 undo log 中上一个版本的指针)。每次 UPDATE 都会创建一个新版本，并用 DB_ROLL_PTR 链接到旧版本，形成一个版本链。
     • 读视图 (Read View)：当事务执行 SELECT 时，会生成一个 Read View。它包含：当前活跃的事务ID列表 (m_ids)、活跃事务中的最小ID (min_trx_id) 和下一个将要分配的事务ID (max_trx_id)。
     • 可见性判断：遍历版本链，对于每个版本，通过其 DB_TRX_ID 和 Read View 进行比较：
       • 若 DB_TRX_ID < min_trx_id，说明这个版本在当前事务开始前就已提交，可见。
       • 若 DB_TRX_ID >= max_trx_id，说明这个版本是未来才创建的，不可见。
       • 若 min_trx_id <= DB_TRX_ID < max_trx_id，则检查 DB_TRX_ID 是否在 m_ids 列表中。如果在，说明是未提交的并发事务，不可见；如果不在，说明已提交，可见。

2. 追问：既然 InnoDB 的 RR 级别能防幻读，为什么不总是用它？RC 有什么优势？

   • 回答要点：
     • 锁的粒度和持有时间：在 RC 级别下，UPDATE 语句的行锁，在语句执行完后就可能释放（如果没命中索引可能会持有更久），而 RR 级别下，行锁和间隙锁会一直持有到事务结束。更长的锁持有时间意味着更低的并发度。
     • 间隙锁 (Gap Lock)：RR 级别为了防止幻读引入了间隙锁，这可能导致在某些场景下出现意想不到的死锁，或者锁住了本不该锁的范围，降低了并发插入的性能。RC 级别没有间隙锁。
     • 快照版本：RC 是语句级快照，RR 是事务级快照。RR 需要保存更老的 undo log 版本，增加了存储开销和回滚段的维护成本。

3. 追问：如果业务确实需要防止幻读，除了用 Serializable 或 InnoDB 的 RR，还有其他方案吗？

   • 回答要点：
     • 显式锁定：在 RC 或 RR 级别下，对需要锁定范围的查询使用 SELECT ... FOR UPDATE 或 SELECT ... FOR SHARE。这会显式地加上 Next-Key Lock (在 RR) 或行锁 (在 RC)，阻止其他事务在范围内插入或修改，从而防止幻读。
     • 物化冲突：将范围查询的冲突转化为唯一键冲突。例如，在预定会议室的场景中，要确保某个时间段内只有一个预定。可以创建一张表，将 (room_id, booking_date, time_slot) 设置为唯一索引。当并发插入时，数据库的唯一性约束会保证只有一个事务能成功，其他事务会因主键冲突而失败。这是一种业务层面的解决方案。