什么是MVCC？看看它的实现原理-六虎

大家好，我是归思君~

之前在讲 MySQL 业务阻隔性提到过，关于写操作给读操作的影响这种景象下产生的脏读、不行重复读、虚读问题，是通过MVCC 机制来进行处理的，那么MVCC到底是怎么完成的，其内部原理是怎样的呢？咱们要捉住三个方面：记载中的4个躲藏字段、undo log 和 read view。

一、MVCC 界说和处理的读问题

1. 业务并发一致性的读问题

脏读（Dirty Read）

脏读也便是当时业务读取到了其他业务还未提交的数据。咱们举个例子来看看：

Time	session A	session B
1	`-设置当时会话业务阻隔等级为：读未提交 set session transaction isolation level read uncommitted;`
2	`-设置当时会话业务阻隔等级为：读未提交 set session transaction isolation level read uncommitted;`
3	`start transaction; select * from account;`
4	`start transaction; select * from account; update account set user_name = '孙七' where id = 6;`
5	`select * from account;` 查询到了session B 中还没有提交的数据

不行重复读(Non-Repeatable Read)

不行重复读是两次读取的成果不相同，和脏读的差异便是不行重复读读到了其他业务提交后的数据。

举个实例来看看：

Time	session A	session B
1	`-设置当时会话业务阻隔等级为：读已提交 set session transaction isolation level read committed;`
2	`-设置当时会话业务阻隔等级为：读已提交 set session transaction isolation level read committed;`
3	`start transaction; select * from account;`
4	`start transaction; select * from account; update account set user_name='赵赵' where id = 1; -此刻现已产生修正 select * from account;`
5	`select * from account;`
6	`commit;`
7	`select * from account;` 关于未提交的业务，查询不到。相关于前一个阻隔等级，杜绝了未提交业务修正对别的会话的影响。一旦别的的会话提交后，在进行查询时，会查出相应的修正。即在一个完整会话中，前后查询不同。

虚读（Phantom）

所谓虚读，也便是根据某些搜索条件先后查询数据库，发现两次查询成果条数不同。和不行重复读的差异便是不行重复读的条数没有变化，虚读条数因为修正操作形成了条数变化。

下面举个实例来阐明：

Time	session A	session B
1	`-设置当时会话业务阻隔等级为：可重复读 set session transaction isolation level repeatable read; select @@transaction_isolation;`
2	`-设置当时会话业务阻隔等级为：可重复读 set session transaction isolation level repeatable read; select @@transaction_isolation;`
3	`start transaction; select * from account;`
4	`start transaction; select * from account; insert into account values(7,'刘八',100); -此刻现已产生修正 select * from account;`
5	`select * from account;`
6	`commit;`
7	`select * from account; insert into account values(7,'刘八',100);` 尽管此刻查询全表没有发现新的数据，但是这个时候刺进和session B 中相同的刺进语句却提示存在一条 key = 7 的语句，阐明 session B 的操作确实影响到了 session A 。这便是虚读

2.MVCC的界说

全称叫 Multi-Version Concurrency Control 的多版别并发操控。也便是指“保持一个数据的多个版别，使得读写操作没有抵触”。

在阐明 MVCC 原理前，先了解一下 InnoDB 的当时读和快照读：

当时读

当时读，也便是它读取的是记载的最新版别，并且还要确保其他并发业务不能修正当时记载，完成方法是对读取记载进行加锁。比方下面给出的都是当时读

#同享锁
select lock in share mode;
select for update;
#排他锁
update
insert
delete

快照读

快照读是一种根据多版别并发操控（MVCC）的不加锁读取形式，由于多版别操控，使得快照读读到的可能不是数据的最新版别。比方不加锁的select 操作便是快照读。

二、MVCC 完成原理

1. 记载的三个躲藏字段

关于InnoDB 存储引擎来说，它的每条聚簇索引记载中都包括有以下三个躲藏字段：

row_id：躲藏主键。假如该数据表中没有设置主键，就会自动生成一个6字节的row_id
roll_pointer：回滚指针。指向旧版别的 undo 日志
trx_id：最近修正记载的业务ID。记载创立这条记载或者最终一次修正该记载的业务ID

如图所示，row_id 标明该记载生成的仅有隐式主键；trx_id 标明当时操作该记载的业务ID；roll ptr 是指向上一版别的 undo 日志的地址。

2. undo 日志

undo log 便是回滚日志，之前在业务的原子性中介绍过，它是确保业务原子性的机制。undo 日志保存的只有 insert、delete 和 update这些修正记载的操作。下面举个例子来帮助了解 undo log 的履行流程：

1.有一个业务编号为1 的业务向数据表中刺进一条记载，此刻业务的状态是：
- row_id：躲藏主键为1
- trx_id：创立该记载的业务ID
- roll ptr：其上个版别的 undo 日志为空
2.第二个业务编号为2的业务对该记载进行修正，将name 字段的 ethan 改为 bob。此刻的操作有：
- 修正数据时，数据库会对该行加排他锁
- 把该行数据复制一份到 undo log 中
- 复制完成后，再修正该记载name 字段的 ethan 为 bob、修正躲藏字段的业务ID 为2，回滚指针指向复制到 undo log 的记载。
- 业务提交后开释排他锁
3.若第三个业务ID 为 3 对记载的age 字段进行了修正，将 20 修正为 18，则会呈现：
- 业务3修正记载时，数据库对该行加排他锁
- 数据库将该行数据复制到 undo log 中
- 复制完毕后将该记载字段的 age 改成 18。修正躲藏业务ID 为 3，回滚指针指向上个版别的地址
- 业务提交后开释锁

从第2次咱们会发现，undo log 中会呈现多个版别的日志。这便是版别链。链首是最新的旧记载，链尾是最早的旧记载。

3. ReadView(读视图)

ReadView 界说

ReadView 是业务进行快照读那一刻，生成的一个数据体系当时的快照，记载并维护当时活泼业务的id，并且这个 ID 值是递增的。ReadView 的作用便是用来做可见性判别，记载当时业务履行快照读时，创立的ReadView 能够看到哪些版别的数据。

那么是ReadView 是怎么判别的呢？

ReadView 版别可见性判别规矩

在ReadView 视图中主要有四个重要的特点：

trx_list: 一个数值列表，当时体系活泼的读写业务的业务id 列表
min_trx_id: trx_list 中最小的业务id，trx_list 中的最小值
max_trx_id: 不是trx_list 的最大值，它是指体系应该分配给下一业务的业务id 值
- 比方现在 trx_list 中有id 为1、2、3、4的业务，那么max_trx_id 的值便是5
creator_trx_id：生成该 ReadView 业务的业务ID

在拜访某条记载时，只需求按照下面的步骤来判别记载的某个版别是否可见：

1.(trx_id == creator_trx_id)若被拜访版别的trx_id值与当时 ReadView 中的 creator_trx_id 相同，也便是说当时业务在拜访它自己修正过的记载，该版别能够被当时业务拜访。
2.(trx_id < min_trx_id)若被拜访版别的trx_id 值小于 ReadView 的 min_trx_id 值，标明生成该版别的业务在当时业务生成ReadView 以前现已提交，该版别能够被当时业务拜访。
3.(trx_id >=max_trx_id)若被拜访版别的trx_id 值大于或等于 ReadView 中的 max_trx_id ，标明生成该版别的业务在当时业务生成 ReadView 后才开启，该版别能够被当时业务拜访。
4.(min_trx_id <trx_id < max_trx_id)若被拜访版别的trx_id 值介于 ReadView 的 min_trx_id 和 max_trx_id 值之间，需求判别trx_id 特点值是否存在 trx_list 中
- 假如存在，阐明创立 ReadView 时生成该版别的业务仍是活泼的，该版别不行以被拜访
- 假如不存在，阐明创立 ReadView 时生成该版别的业务现已被提交，因而该版别能够被拜访

假如某个版别的数据对当时业务是不行见的，那就顺着版别链找到下一个版别数据，持续履行上面的步骤来判别记载的可见性，顺次类推。知道版别中的最终一个版别。假如记载的最终一个版别也不行见，意味着该条记载对当时业务彻底不行见，查询成果就不包括该记载。

举例

下面让咱们来看看 MVCC 完成的详细流程是怎样的，如下表是业务ID 为2 的业务对某行数据履行了快照读，其中的列表如下：

业务1	业务2	业务3	业务4
业务开端	业务开端	业务开端	业务开端
…	…	…	修正且已提交
进行中	快照读	进行中
…	…	…

那么此刻ReadView 的参数值为：

trx_list：业务1、2、3
min_trx_id：业务1
max_trx_id：业务5
creator_trx_id：业务2

以业务4 版别为例，咱们通过上述规矩来比较看当时ReadView 能否看见业务4版别的数据：

经比较，只有第四条规矩满意。此刻trx_id 的值是介于min_trx_id 和 max_trx_id 之间，但是不在 trx_list 中，因而经判别该业务现已提交。所以该版别能够被拜访。

其实这个规矩很好了解，在活泼业务列表里面的，意味还没有提交，除了创立ReadView 的当时业务，其他的业务都不行见。不在列表里面的阐明都现已提交，自然能够看见。如下图除了黄色和红色不行见，其他的版别都可见。

三、MVCC 怎么处理脏读、不行重复读和虚读

首要回忆一下MySQL的业务阻隔等级中的视图

读未提交(RU)：它是直接返回记载的最新值，没有视图
读已提交(RC)：每次查询都会创立一个ReadView
可重复读(RR)：这个ReadView是在业务启动时创立，整个业务存在期间都用这个ReadView
串行化(serializable)：直接用加锁的方法来避免并行拜访

1.MVCC 处理脏读

在读已提交的MVCC 中，每次查询都会创立一个 ReadView 。由于版别操控的可见性规矩，使得当时业务只看的到现已提交的数据，所以这样就避免了看见未提交的数据，然后处理了脏读。

2.MVCC 处理不行重复读

因为RC 等级每次查询都会创立一个 ReadView ，所以关于已提交的业务，由于不能共用一个ReadView ，仍是会形成两次读取过程中的不行重复读。所以RR 等级通过运用从启动到结束运用一个 ReadView，来处理提交两次查询读取不一致的现象。

3.MVCC 到底能不能处理虚读？

先说结论：MVCC能够处理“快照读”，无法处理“当时读”

MVCC 能够处理“快照读”

MVCC 能够处理如不加锁的select。原理便是MVCC 运用快照来操控版别数据读取的范围，然后在 RR 等级避免了虚读。在我上面讲虚读的举例就阐明晰，在select 快照读时，没有发现新的数据。但是新刺进相同的数据却报错，阐明MVCC 无法彻底处理虚读。

MVCC 无法处理“当时读”

假如在select 上加锁，运用“当时读”，虚读仍是会呈现。所以真实要处理虚读，仍是得用加锁的形式来处理。所以一般来说，也只有串行化等级才能真实处理虚读。

参考资料

www.cnblogs.com/kismetv/p/1…

pdai.tech/md/db/sql-m…

time.geekbang.org/column/arti…

blog.csdn.net/qq_35590091…

《MySQL是怎样运转的-从根儿上了解MySQL》

本文参加了1024 程序员节活动，欢迎正在阅读的你也参加。

什么是MVCC？看看它的实现原理