数据库写轮眼：看透 MVCC 版本链、快照、隔离级别。-优快云博客

引言：

在数据库高并发场景下，海量事务同时读写同一份数据，单纯依赖锁机制相互制衡，只会造成无休止的阻塞等待；脏读、不可重复读与幻读，更如同忍界无解的幻术，牢牢桎梏着系统性能。

正如这幅图中，宇智波鼬借 Undo Log 铺展绵延不绝的数据历史分身版本链，佐助则凭借 ReadView 写轮眼，筛选出仅对当前事务可见的数据快照。

MVCC 正是数据库世界里独一份的宇智波瞳术，它摒弃锁竞争的对抗思路，依托多版本数据与视图可见性规则，为每一笔事务划分独立读写时空，从根源化解并发读写矛盾。

为什么需要 MVCC？

多事务并发访问数据库时，会引发脏读、不可重复读、幻读等并发异常。

为平衡数据一致性与并发性能，数据库提供了不同事务隔离级别。传统悲观锁方案也可以解决问题，但是并发效率低。

因此数据库设计者想设计一种办法既保证事务隔离，又尽量不加锁。于是MVCC 出现了。

MVCC是什么？是如何实现的？

先思考一个问题：如果事务A正在读一条数据1000，事务B把它改为2000。那么事务A应该看到哪个值？

不同隔离级别要求不同：

Read Committed 希望看到最新已提交版本

Repeatable Read 希望永远看到第一次读取的版本

所以本质问题变成了：一条数据到底应该给事务看哪个版本？

既然不同事务想看不同版本。那么最直接的方法就是：保存多个历史版本。

核心思想为数据维护多个历史版本，让不同事务读取不同版本的数据，实现无锁读，提升数据库并发性能

底层实现：

MVCC 依靠隐藏字段、undo log、ReadView三大核心组件协作，完成数据版本管理与可见性判断。

表隐藏字段：

每张数据表默认包含两个关键隐藏字段：

trx_id(事务ID)：记录最后修改该条数据的事务 ID（事务 ID 全局自增，可判断事务先后顺序）；
roll_pointer（回滚指针）：指向undo log中的历史数据版本，将所有版本串联成版本链表，用于追溯历史数据。

undo log（回滚日志）：

每次数据被修改时，会将修改前的旧数据存入 undo log，生成一个新数据版本；
依靠回滚指针串联所有历史版本，形成版本链；
作用：既支持事务回滚，也为 MVCC 提供历史数据版本。

ReadView（读视图）

ReadView 是事务读取数据时的可见性判断规则，用来判定某条数据版本对当前事务是否可见，包含 4 个核心字段：

creator_trx_id：创建当前 ReadView 的事务 ID；
m_ids：创建视图时，数据库中所有活跃（未提交）的事务 ID 集合；
min_trx_id：活跃未提交事务中的最小事务 ID；
max_trx_id：数据库下一个待分配的新事务 ID。

数据版本可见性判断规则

对比数据版本的trx_id与ReadView 字段，分三类场景判断可见性：

数据 trx_id < min_trx_id：该版本在 ReadView 创建前就已提交，当前事务可见；
数据 trx_id ≥ max_trx_id：该版本是 ReadView 创建后新启动的事务生成，当前事务不可见；
min_trx_id < 数据 trx_id < max_trx_id：
1. 若 trx_id 存在于m_ids（事务未提交）：不可见；
2. 若 trx_id 不存在于m_ids（事务已提交）：可见。

一句话总结MVCC：

MVCC本质上由两部分组成分别是Undo Log和ReadView。Undo Log用来保存历史版本，ReadView负责判断哪个版本对当前事务可见。

修改数据时，记录事务 ID 到隐藏字段、旧数据存入 undo log 形成版本链；查询数据时，通过 ReadView 对比事务 ID，判断版本可见性，最终读取对应版本数据。

各个隔离级别是如何实现的？

读未提交：最低的隔离级别, 每个事务都可以看到其他事务未提交的数据.

读已提交：解决了脏读的问题，每个事务只能读到其他事务已经提交的数据。

可重复读：mysql默认的隔离级别，解决了脏读和不可重复读。同一个事务内永远读到第一次查询的快照数据。

串行化：事务完全串行执行，不允许并发，底层实现是加锁。