MySQL 中的事务隔离级别有哪些？

MySQL 事务隔离级别详解

【核心定义】

事务隔离级别是数据库管理系统用于控制多个并发事务之间可见性和相互影响程度的一组标准规则，其本质是在数据一致性、并发性能和数据准确性三者之间进行权衡。

【关键要点】

1. READ UNCOMMITTED（读未提交）

   • 结论：最低的隔离级别，允许事务读取其他未提交事务的修改（脏读）。
   • 原理：事务之间几乎无隔离，读取操作不加锁或使用极弱的锁机制，性能最高但数据一致性最差。

2. READ COMMITTED（读已提交）

   • 结论：大多数数据库的默认级别（如Oracle），保证事务只能读取到其他已提交事务的数据。
   • 原理：通过行级锁或MVCC（多版本并发控制）的快照读机制实现，每次SELECT都会读取最新的已提交数据快照，避免了脏读。

3. REPEATABLE READ（可重复读）

   • 结论：MySQL InnoDB引擎的默认隔离级别，保证在同一事务中多次读取同一数据的结果一致。
   • 原理：通过MVCC机制，在事务开始时创建一致性视图，后续所有读操作都基于该视图，避免了不可重复读。

4. SERIALIZABLE（串行化）

   • 结论：最高的隔离级别，完全串行执行事务，性能最低但数据一致性最强。
   • 原理：通过表级锁或Next-Key Lock（间隙锁+行锁） 强制事务串行执行，避免了所有并发问题。

【深度推导/细节】

核心矛盾：并发问题与隔离级别的对应关系

隔离级别	脏读	不可重复读	幻读	性能
READ UNCOMMITTED	❌ 可能发生	❌ 可能发生	❌ 可能发生	⭐⭐⭐⭐⭐
READ COMMITTED	✅ 避免	❌ 可能发生	❌ 可能发生	⭐⭐⭐⭐
REPEATABLE READ	✅ 避免	✅ 避免	❌ 可能发生*	⭐⭐⭐
SERIALIZABLE	✅ 避免	✅ 避免	✅ 避免	⭐

注：MySQL的REPEATABLE READ通过Next-Key Lock机制部分解决了幻读，但仍有边界情况。

MySQL InnoDB的MVCC实现机制（REPEATABLE READ级别）

Step 1 - 隐藏字段：

• DB_TRX_ID：最近修改该行的事务ID
• DB_ROLL_PTR：指向undo log中旧版本数据的指针
• DB_ROW_ID：隐藏的自增行ID

Step 2 - Read View创建：

• 事务首次执行SELECT时创建Read View
• 包含：当前活跃事务ID列表、最小活跃事务ID、下一个将分配的事务ID

Step 3 - 可见性判断：

1. 如果DB_TRX_ID < 最小活跃事务ID → 可见（事务已提交）
2. 如果DB_TRX_ID >= 下一个事务ID → 不可见（事务后开始）
3. 如果DB_TRX_ID在活跃事务列表中 → 不可见（事务未提交）
4. 否则通过DB_ROLL_PTR在undo log中查找合适的历史版本

幻读问题的特殊处理

MySQL REPEATABLE READ的”半解决”方案：

• 快照读（普通SELECT）：通过MVCC避免幻读
• 当前读（SELECT … FOR UPDATE/LOCK IN SHARE MODE）：通过Next-Key Lock避免幻读
  • Next-Key Lock = 行锁 + 间隙锁
  • 间隙锁锁定索引记录之间的间隙，防止其他事务插入

【关联/对比】

MySQL vs Oracle的默认隔离级别

特性	MySQL (InnoDB)	Oracle
默认级别	REPEATABLE READ	READ COMMITTED
实现方式	MVCC + Next-Key Lock	MVCC（基于SCN）
幻读处理	部分解决（当前读时）	可能发生

隔离级别与锁的关系演进

• READ UNCOMMITTED：几乎无锁，或只有写锁
• READ COMMITTED：行级写锁，读不加锁（MVCC）
• REPEATABLE READ：行级写锁 + 间隙锁（当前读时）
• SERIALIZABLE：表级锁或严格的Next-Key Lock

【版本差异】

MySQL 5.x vs 8.0的重要变化

1. 信息查询方式变化：

   • 5.x：SELECT @@tx_isolation
   • 8.0：SELECT @@transaction_isolation

2. 数据字典变化：

   • 8.0将事务元数据存储在数据字典表中，支持原子DDL

3. 性能优化：

   • 8.0改进了MVCC的垃圾回收机制，减少undo log的空间占用

『面试官追问』

1. 为什么MySQL选择REPEATABLE READ作为默认级别，而Oracle选择READ COMMITTED？

   • MySQL更注重数据一致性，适合OLTP场景
   • Oracle更注重并发性能，适合高并发OLAP场景

2. MVCC是如何解决读写冲突的？

   • 写操作创建新版本，读操作访问旧版本
   • 通过undo log链维护多个版本
   • 垃圾回收机制清理不再需要的旧版本

3. 什么情况下会出现”丢失更新”问题？各隔离级别如何应对？

   • 两个事务同时读取并修改同一数据，后提交的覆盖先提交的
   • READ COMMITTED和REPEATABLE READ都可能发生
   • 解决方案：使用SELECT … FOR UPDATE或乐观锁

4. 如何在实际项目中合理选择隔离级别？

   • 金融系统：REPEATABLE READ或SERIALIZABLE
   • 电商系统：READ COMMITTED（大部分场景）
   • 报表系统：READ UNCOMMITTED（允许脏读）

5. MySQL的REPEATABLE READ真的完全解决了幻读吗？

   • 不完全。当使用普通SELECT（快照读）时，如果其他事务插入数据并提交，当前事务的后续UPDATE/DELETE操作可能影响这些”新”行，造成逻辑上的幻读。

---

总结要点：理解MySQL事务隔离级别的关键在于掌握MVCC的实现机制和Next-Key Lock的工作原理，同时明确不同级别在一致性、并发性和性能之间的权衡关系。在实际开发中，应根据业务场景的敏感度合理选择隔离级别，必要时配合显式锁机制确保数据一致性。