一篇文章带你了解 ：MySQL MVCC
很多一提到 MVCC 就会说“版本链”，但具体版本链长什么样、怎么判断哪个版本对自己可见，往往说不清楚。其实 MVCC 的本质就是通过“版本链”来控制并发事务访问同一个记录时的行为。
一、 MVCC 的“底层装备”：隐藏列与 Undo Log
要实现多版本，数据库必须得记录下数据的“前世今生”。在 InnoDB 中，每行数据后面其实都偷偷藏了两个关键的隐藏列：
trx_id：记录最后一次修改该行数据的事务 ID。每次事务对某条聚簇索引记录进行修改时，都会把自己的事务 ID 赋值给这个字段。
roll_pointer：回滚指针。它指向undo log里的旧版本数据。通过它，我们可以把一行的所有旧版本串成一个版本链，从而实现数据回溯。
当你修改数据时，旧数据不会被直接抹掉，而是进入了 undo log。这个版本链就是 MVCC 实现快照读的物理基石。
二、 核心工具：Read View（一致性视图）
光有版本链还不够，我怎么知道该读链条上的哪一个版本呢？这时候就需要Read View出马了。
Read View 就像是一个“时间快照”，记录了当前系统里有哪些事务还没提交。它包含四个核心字段：
m_ids：创建 Read View 时，当前系统中活跃的（即正在运行中、还没提交的）事务 ID 列表。
min_trx_id：活跃事务中最小的那个 ID。
max_trx_id：即将分配给下一个事务的 ID（也就是最大活跃 ID + 1）。
creator_trx_id：创建该 Read View 的事务自己的 ID。
三、 判定原理：我到底能看到谁？
当我们要查询一条数据时，会拿该数据版本里的trx_id去跟 Read View 里的这几个字段做对比。逻辑其实非常质朴，主要分为以下几种情况：
1. 确定可见的情况
trx_id < min_trx_id：说明生成这个版本的事务在你开启视图前就已经提交了，数据可见。
trx_id 不在 m_ids 中：即便 ID 比较大，但如果它不在活跃列表里，说明该事务也已经提交，数据可见。
trx_id == creator_trx_id：这就是你自己改的数据，当然可见。
2. 确定不可见的情况
trx_id > max_trx_id：说明这个版本是在你开启视图之后才开启的事务生成的，属于“未来的数据”，不可见。
trx_id 在 m_ids 中：说明生成这个版本的事务还没提交，读它就是“脏读”，不可见。
实战逻辑：如果你发现当前版本按规则不可见，系统就会顺着roll_pointer往回找旧版本，直到找到第一个符合可见性规则的版本为止。
四、 RC 与 RR：Read View 生成时机的差异
这是面试中最爱深挖的考点：为什么 MVCC 能解决不可重复读？区别全在 Read View 的生成时机上。
读提交 (Read Committed)：每次执行 SELECT 语句前，都会重新生成一个新的 Read View。
结果：如果在你两次查询之间有别人提交了事务，第二次查询生成的 Read View 就不再包含那个事务，你就能看到新数据。这就导致了“不可重复读”。
可重复读 (Repeatable Read)：只在执行第一条 SELECT 时生成一个 Read View，后面所有的查询都复用这一个。
结果：即便中间有别人提交了，你用的还是最初那个 Read View，看到的依然是当初那个快照版本。这就是实现“可重复读”的秘诀。
五、 总结：MVCC 到底解决了什么？
MVCC 的出现，让数据库在并发处理上有了质的飞跃：
读写并行：它通过Undo Log保存历史版本，配合Read View决定可见性，让“快照读”不需要加锁。
性能提升：避免了大量的锁竞争，让数据库在高并发下依然能保持极高的吞吐量。