MySQL 事务的隔离级别有哪些？（详解数据库并发控制与幻读机制）

在数据库高并发场景下，事务隔离级别（Transaction Isolation Levels）是保障数据一致性与系统性能之间平衡的关键机制。SQL 标准定义了四种隔离级别，而 MySQL 的 InnoDB 存储引擎不仅完整实现了这四种级别，还通过独特的 MVCC（多版本并发控制）和锁机制（如间隙锁）对标准进行了增强。很多开发者容易混淆“不可重复读”与“幻读”的区别，也不理解为何 MySQL 默认选择 RR（可重复读）而互联网大厂却倾向于 RC（读已提交）。本文将基于 2026 年的最新实践，深度解析各隔离级别的特性、底层实现原理及选型策略。

SQL 标准定义的四种事务隔离级别

根据 ANSI/ISO SQL 标准，事务隔离级别从低到高依次为：读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read） 和 串行化（Serializable）。隔离级别越高，数据一致性越强，但并发性能越低。

1. 读未提交（Read Uncommitted, RU）

• 定义：允许一个事务读取另一个事务尚未提交的修改。
• 特点：
  • 隔离性最差：几乎没有任何隔离保护。
  • 脏读（Dirty Read）：这是该级别最致命的问题。事务 A 修改了数据但未提交，事务 B 读取到了这个“脏数据”。如果事务 A 随后回滚，事务 B 读取的数据就是无效的，导致数据逻辑错误。
  • 不可重复读与幻读：必然存在。
• 应用场景：极少在生产环境使用。仅适用于对数据准确性要求极低、追求极致读取速度的统计分析场景（如实时大屏展示近似值），且业务逻辑能容忍脏数据。

2. 读已提交（Read Committed, RC）

• 定义：一个事务只能读取到其他事务已经提交的修改。
• 特点：
  • 解决脏读：确保读取到的数据都是持久化的。
  • 不可重复读（Non-Repeatable Read）：在同一事务内，两次读取同一行数据，结果可能不同。因为其他事务可能在两次读取之间提交了对该行的修改。
  • 幻读（Phantom Read）：依然存在。在同一事务内，两次执行相同的范围查询（如 SELECT * FROM t WHERE age > 10），第二次可能会读出第一次没读到的新行（其他事务插入并提交的数据）。
  • 快照机制：在 RC 级别下，InnoDB 会在每条 SELECT 语句执行时生成一个新的 Read View（快照），因此每次读取都能看到最新的已提交数据。
• 应用场景：大多数互联网业务的首选。如电商订单查询、用户信息浏览等，允许少量不一致以换取更高的并发吞吐量。Oracle、SQL Server 的默认级别即为 RC。

3. 可重复读（Repeatable Read, RR）

• 定义：确保在同一事务内的多次读取，能看到一致的数据视图，即使其他事务提交了修改。
• 特点：
  • 解决脏读与不可重复读：这是其核心优势。
  • 幻读问题：在 SQL 标准中，RR 级别仍允许幻读。但在 MySQL InnoDB 引擎中，通过引入 Next-Key Lock（临键锁 = 记录锁 + 间隙锁） 和 MVCC 的组合拳，在绝大多数场景下避免了幻读。
    • 注意：在某些极端复杂场景（如先快照读后当前读）下，MySQL 的 RR 级别仍可能出现幻读，但这属于特例。
  • 快照机制：在 RR 级别下，InnoDB 仅在事务启动后的第一次 SELECT 语句执行时生成一个 Read View，并在整个事务期间复用该快照。因此，无论其他事务如何修改提交，当前事务看到的始终是事务开始时的数据状态。
• 应用场景：对数据一致性要求较高的场景，如金融转账、库存扣减、报表统计等。也是 MySQL 的默认隔离级别。

4. 串行化（Serializable）

• 定义：强制事务串行执行，相当于给所有读取的数据行加上共享锁，给写入的数据行加上排他锁。
• 特点：
  • 解决所有问题：彻底杜绝脏读、不可重复读和幻读。
  • 性能最低：并发能力极差，极易产生大量的锁等待和超时，吞吐量大幅下降。
  • 实现方式：InnoDB 会将普通的 SELECT 语句隐式转换为 SELECT ... LOCK IN SHARE MODE（或类似机制），强制加锁。
• 应用场景：极少使用。仅用于对数据一致性要求极其严苛且并发量极低的特殊场景，或者作为调试手段。

MySQL 默认隔离级别及其深层原因

默认级别：可重复读（Repeatable Read）

在 MySQL 5.7 及 8.0+ 版本中，InnoDB 引擎的默认隔离级别均为 RR（Repeatable Read）。可以通过以下命令查看：

SELECT @@transaction_isolation; 
-- 或旧版本：SELECT @@tx_isolation;
-- 输出：REPEATABLE-READ

为什么 MySQL 默认选择 RR 而不是 RC？

这是一个经典的架构权衡问题，主要基于以下三点考量：

1. 主从复制（Replication）的历史兼容性
   在 MySQL 早期版本中，主从复制主要依赖 Statement 格式 的 Binlog（记录 SQL 原文）。在 RC 级别下，由于每次读取的快照不同，主库和从库在执行相同的 SQL 时（特别是涉及函数如 NOW(), UUID() 或LIMIT 偏移量时），可能会因为执行时序差异导致数据不一致。而 RR 级别保证了事务内读取的一致性，使得 Statement 格式的 Binlog 在主从回放时能产生相同的结果。虽然现代 MySQL 推荐使用 Row 格式 Binlog 来解决此问题，但为了保持向后兼容和默认配置的稳健性，RR 被保留为默认值。
2. 更强的数据一致性保障
   对于通用型数据库，默认配置应偏向“安全”而非“性能”。RR 级别能有效防止不可重复读，为大多数 OLTP（在线事务处理）应用提供更强的一致性保证，避免开发者因疏忽而写出依赖特定读取时序的代码。
3. InnoDB 的幻读优化
   由于 InnoDB 通过 Next-Key Lock 在 RR 级别下基本解决了幻读问题，使得 RR 在实际体验上接近串行化，但性能损耗远小于 Serializable。这使得 MySQL 的 RR 级别成为了一个“性价比”极高的默认选项。

深度解析：不可重复读 vs 幻读

很多面试者容易混淆这两个概念，它们的本质区别在于修改的对象不同。

示例说明：

• 不可重复读：你查银行卡余额是 100 元，别人给你转了 50 元并提交。你再查一次变成 150 元。这就是不可重复读（针对同一行）。
• 幻读：你查部门里“年龄大于 30 岁”的员工有 5 人。HR 新入职了一个 35 岁的员工并提交。你再查“年龄大于 30 岁”的员工变成了 6 人。虽然前 5 人的数据没变，但总数变了，就像出现了“幻觉”。

互联网大厂为何倾向将隔离级别改为 RC？

尽管 MySQL 默认是 RR，但在 2026 年的互联网行业（如阿里、腾讯、美团等），大量核心业务将隔离级别调整为了 RC（Read Committed）。主要原因如下：

1. 提升并发性能
   RR 级别需要使用 Next-Key Lock（间隙锁），这会锁定索引记录之间的空隙。在高并发写入场景下，间隙锁容易导致大量的锁冲突和死锁，降低吞吐量。而 RC 级别仅使用 Record Lock（行锁），不锁间隙，显著减少了锁竞争，提升了并发写入能力。
2. 减少长事务影响
   在 RR 级别下，长事务会一直持有启动时的 Read View，导致 Undo Log 无法被清理（Purge 线程无法删除旧版本），可能引发 Undo Log 膨胀，甚至拖慢整个实例的性能。RC 级别下，每条语句都生成新快照，旧版本数据能更快被回收。
3. 业务逻辑可控
   大多数互联网业务对“不可重复读”和“幻读”并不敏感，或者可以通过应用层的乐观锁、版本号机制来控制一致性。既然 RR 带来的强一致性在业务层未被充分利用，反而牺牲了性能，那么降级到 RC 是更务实的选择。
4. Binlog 格式的演进
   现代生产环境普遍使用 Row 格式 的 Binlog，彻底解决了主从复制在 RC 级别下的数据一致性问题，消除了当初 MySQL 默认选 RR 的最大历史包袱。

总结与选型建议

最终建议：

• 若你的业务是金融、支付、库存等对数据一致性极度敏感的场景，请保持 MySQL 默认的 RR 级别，利用其强大的锁机制保障安全。
• 若你的业务是电商、社交、内容平台等高并发、读写频繁且能容忍短暂不一致的场景，建议显式将隔离级别调整为 RC，以释放更高的系统吞吐量，并通过应用层逻辑弥补一致性的微小缺口。