文章目录
-
-
- [1. 隔离性与 MVCC 的层级关系](#1. 隔离性与 MVCC 的层级关系)
- [2. MVCC 是如何定制化实现隔离性的？](#2. MVCC 是如何定制化实现隔离性的？)
- [3. MVCC 与锁的协作](#3. MVCC 与锁的协作)
- [4. 为什么不直接用 MVCC 实现所有隔离级别？](#4. 为什么不直接用 MVCC 实现所有隔离级别？)
- 总结
-
简单来说，隔离性是"目标"，而 MVCC 是实现这个目标的"手段"之一。
在数据库的 ACID 特性中，隔离性（Isolation）要求并发执行的事务之间不能互相干扰。为了达到这个目标，数据库可以采用"全加锁"的硬办法，也可以采用 MVCC 这种更聪明的办法。
1. 隔离性与 MVCC 的层级关系
我们可以用一个架构图的视角来理解：
- 隔离性 (Isolation) ：处于需求层。它定义了四个级别（RU, RC, RR, Serializable），规定了事务之间能看到什么，不能看到什么。
- MVCC ：处于实现层 。它通过"版本链"的技术，专门用来实现 RC（读已提交） 和 RR（可重复读） 这两个级别，目的是在保证隔离性的同时，不损失并发性能。
2. MVCC 是如何定制化实现隔离性的？
隔离性的核心差异在于**"可见性"**，而 MVCC 巧妙地通过控制 Read View（读视图）的生成时机，实现了不同的隔离级别：
RC（读已提交）的实现逻辑：
- 规则 ：事务中的每一次
SELECT都会实时生成一个新的 Read View。 - 结果：因为每次都更新 Read View，所以如果另一个事务在两次查询之间提交了，第二次查询就能看到新提交的数据。这实现了 RC 的定义，但也产生了"不可重复读"。
RR（可重复读）的实现逻辑：
- 规则 ：事务中只有第一次
SELECT时会生成 Read View，之后的查询全部复用这一个。 - 结果：即使别的事务提交了千万次，由于你手里拿的是开启事务时的那张"老照片"，你看到的永远是一致的数据。这完美实现了 RR 的定义。
3. MVCC 与锁的协作
隔离性的完整实现，其实是 MVCC + 锁 的组合拳：
- 快照读（Snapshot Read） ：靠 MVCC 实现隔离性。不需要加锁，并发极高。
- 当前读（Current Read） ：靠 锁（Locking） 实现隔离性。比如
SELECT ... FOR UPDATE或者是UPDATE语句，必须通过加锁确保读取和修改的是最新且唯一的版本。
总结： 隔离性如果不靠 MVCC，就只能全靠锁。全靠锁的数据库就像是单行道，而有了 MVCC 的隔离性就像是立体交叉路口，大大提升了效率。
4. 为什么不直接用 MVCC 实现所有隔离级别？
- RU (Read Uncommitted)：太低级了，直接读最新数据就行，连版本链都懒得看，不需要 MVCC。
- Serializable (串行化)：太高级了，要求绝对的排队执行，必须全加锁，MVCC 这种"快照"逻辑无法满足这种严苛的强一致性要求。
因此，MVCC 是专门为 RC 和 RR 量身定做的"性能加速器"。
总结
隔离性是老板提的业务需求 （"我要求事务 A 不能受事务 B 干扰"），而 MVCC 是程序员给出的技术方案（"没问题，我给他们每人发一个不同时间点的快照，让他们各看各的"）。
理解了这一点，你就能明白为什么在谈论隔离性时，MVCC 永远是绕不开的主角了。
既然聊到了这里，你觉得在分布式事务（比如你用过的 Seata AT 模式）中，它是怎么在多个服务之间保持这种隔离性的？