MySQL--深入理解MVCC机制原理

什么是MVCC？

MVCC全称 Multi-Version Concurrency Control，即多版本并发控制，维持一个数据的多个版本，主要是为了提升数据库的并发访问性能，用更高性能的方式去处理数据库读写冲突问题，实现无锁并发。

什么是快照读和当前读？

快照读：不加锁非阻塞读，快照读要求数据库隔离级别不能是串行化，否则会退化到当前读，快照读是基于多版本并发控制的，因为是基于多版本并发控制，所以快照读可能读取的不是最新的数据。
当前读：当前读就是读取最新的数据版本，快照读读取的时候，会对读取的数据加锁，读取的时候其他事务不能修改当前数据。

MVCC和快照读、当前读的关系?

MVCC 多版本并发控制，而快照就是数据的一个版本，MVCC 的无锁并发就是依赖快照读机制实现的。

MVCC的实现原理?

MVCC 实现依赖于数据库记录中的三个隐式字段、undo日志、Read View 版本链，本篇讨论皆基于 MySQL 的 InnoDB 存储引擎。

三个隐式字段：

隐式字段，是我们正常来看看不到的字段，数据库的每行数据除了我们看到的字段之外，还有三个我们看不到的字段。

DB_TRX_ID：记录当前事务最后一次修改的事务ID，即事务 ID，事务 ID 是递增的。
DB_ROW_ID：隐藏的自增主键ID，如果数据库没有主键ID，数据库会自动生成一个 6个字节的 DB_ROW_ID。
DB_ROLL_PTR：回滚指针，指向上一个数据版本。

简单图例：

undo log 日志：

我们都知道undo log 日志是回滚日志，是数据库保证数据一致性的一个支撑，当出现异常情况时候，通过 undo log 日志来进行数据回滚，其实它还有其他作用，undo log 又分为两种，如下：

insert undo log，insert 操作时候产生的日志，只会在发生异常需要进行回滚的时候使用，事务提交后，undo log 就没有用处了，就会被丢弃。
update undo log 和 delete undo log，这两类 undo log 不仅在事务回滚时候要用到，同时在快照读的时候也会用到。

undo log 也会记录一条版本链表，每次修改数据的时候，数据库会先把当前数据拷贝一份到 undo log中，然后再对数据进行修改，最在undo log 中最新修改的数据副本会在链的头部，同时它有一个回滚指针指向他的上一个版本。

Read View：

Read View 是事务执行快照读产生的视图，在事务执行快照读的时候，系统会以当前时刻生成一个快照，以此来维护系统此时活跃的事务id，用来做可见性判断，当某个事务进行快照读的时候，我们根据 Read View 来判断当前事务可以读取哪个版本的数据，然后就去该数据的 undo log 里面找数据，当然也可能是读取最新的数据。

Read View 遵守可见性规则，它的三个属性如下：

trx_list：用来维护 Read View 生成时候系统活跃的事务ID，是一个列表。
up_limit_id：活跃事务ID中最小的ID。
low_limit_id：Read View 生成时候，系统将要分配的下一个事务ID。

可见性算法主要是把要修改的数据的最新版本的事务ID，即DB_TRX_ID取出来，与当前系统中活跃的其他事务ID去对比，而Read View 就维护了这些活跃的事务ID，如果在 Read View 中找不到合适条件的数据记录，就会去 undo log 日志根据回滚指针 DB_ROLL_PTR 来找数据记录直到找到为止。

Read View 的比较流程如下：

注意事务ID 是递增的。

第一步，比较 DB_TRX_ID < up_limit_id，是否小于活跃事务 Read View中最小的事务ID，如果小于，则当前事务能看到 DB_TRX_ID 所在的记录，否则进入第二个判断。
第二步，比较 DB_TRX_ID >=low_limit_id，是否大于等于下一个将要发生的事务ID，如果大于等于则代表 DB_TRX_ID 所在的记录在 Read View生成后才出现的，那对当前事务肯定不可见，否则进入第三个判断。
第三步，判断 DB_TRX_ID 是否在活跃事务 Read View 之中，如果在，则代表我 Read View 生成时刻，你这个事务还在活跃，还没有Commit，你修改的数据，我当前事务也是看不见的，如果不在，则说明，这个事务在 Read View 生成之前就已经 Commit 了，因为第一步、第二步已经判断了是否小于最小活跃事务ID和是否是将要发生的事务ID，两者都不是，同时又不在活跃事务 Read View 中，只能说明在这个事务 Read View 在当前是事务发生之前了，当前事务理所当然能够看到。

简易流程如下：

读已提交(Read Committed)、可重复读(Repeatable Read) 隔离级别下的快照读的区别？

读已提交(Read Committed)、可重复读(Repeatable Read) 隔离级别下的快照读最大的区别就是生成 Read View 时机不同。

可重复读(Repeatable Read) 隔离级别下，一个事务只有在第一次读取数据的时候生成一个Read View，Read View 记录当前活跃的事务ID，后面继续读取数据时候，如果用到快照读，那他使用的还是第一次读取时候的 Read View，这也是为什么可重复读(Repeatable Read) 隔离级别下，看不到别的事务的修改记录的原因。
读已提交(Read Committed) 隔离级别下，事务开启后，每次使用快照读的时候，都会重新生成一个活跃事务ID，第一读取和第二次读取使用的不是同一个 Read View，那第二次读取的时候，第一次读取时候的 Read View 中的某些事务可能已经提交了，那在第二次快照读的时候就可以看到了，这也是在读已提交(Read Committed) 隔离级别下可以看到别的事务提交的记录的原因。

MVCC解决了什么问题？

想要知道MVCC解决了什么问题，我们要先知道数据库多个事务并发访问会有什么问题，数据库并发访问场景如下：

读读并发：多个事务同时读取同一份数据，不存在问题，无需进行并发控制。
读写并发：多个事务同时读写同一份数据，有线程安全问题，可能会脏读、幻读、不可重复度问题。
写写并发：多个事务同时对同一份数据写，可能会有更新丢失的情况。

而MVCC 就是解决以上三种并发中的读写并发问题，是一种无所并发控制，可以解决脏读、不可重复读问题，可以解决部分场景的幻读问题。

什么是幻读？MVCC可以解决幻读问题吗？

MVCC 可以解决快照读的幻读问题，MVCC 机制是依赖快照读、undo log、Read View 来实现的，可以解决快照读的幻读问题，但是不能解决 update、delete 的幻读问题，因为这些操作是当前读。

以下讨论基于可重复读(Repeatable Read) 隔离级别。

当前读幻读演示：

时间	事务A	事务B
1	开始事务
2	第一次查询：select * from user where id > 1;
3		开始事务
4		执行insert： INSERT INTO `user`(id, user_name, user_code, age, address, hobby)VALUES(6, '赵六', 'TC-00000006', 26, '广西', '羽毛球');
5		提交事务
6	第二次查询：select * from user where id > 1;
7	修改数据:update user set name = '赵六国' where id = 6;
8	第三次查询：select * from user where id >1;
9	提交事务

流程解释：

在第2个时间点的时候，快照读，可以得到 id 大于 1的数据。
在第6个时间点的时候，虽然时间点4插入了一条 id 为6的数据，并且在时间点5提交了事务，但是时间点6还是查询不到 id 为6的这条数据，查询结果和第2个时间点的查询结果没有区别。
在第7个时间点的时候，查询结果就有了变化，因为 update 操作是当前读，而事务B在第5个时间点已经提交了一条 id 为6的数据，根据当前读的规则，此刻是可以读取到 id 为6 的数据，也就可以更新 id 为 6 的数据。
第8个时间点的时候，执行第三次查询，此时是基于当前最新版本查询的，所以会查询到事务B提交的 id 为6的数据，对比第一次、第二次查询，多出了 id 为6的数据，这就是幻读。

当前读的幻读问题怎么解决？

加锁解决，关于锁的介绍，传送门如下：

MySQL--锁机制详解

sql 复制代码

#共享锁
SELECT * FROM user LOCK IN SHARE MODE;  
# 排他锁
SELECT * FROM user FOR UPDATE; 
# 排他锁
INSERT INTO  user 
# 排他锁
UPDATE user 
# 排他锁
DELETE FROM  user

注意：INSERT、UPDATE 、DELETE 操作数据库默认加排他锁。

解决幻读问题演示：

时间	事务A	事务B
1	开始事务
2	第一次查询：select * from user where id > 5 lock in share mode;
3	事务A显示加了间隙锁
4		开始事务
5		执行insert： INSERT INTO `user`(id, user_name, user_code, age, address, hobby)VALUES(6, '赵六', 'TC-00000006', 26, '广西', '羽毛球');
6		阻塞了，处于等待状态
7	select * from user where id > 5
8	提交事务
9		事务A提交了，释放了间隙锁，事务B 执行 INSERT 操作
10		提交事务

在第2个时间点的时候，使用 lock in share mode 语法显示加锁了，不仅表中存在的数据加锁了，而且还给 id>5 的区间加了间隙锁。
因为时间点2的操作，给 id>5 的区间加了间隙锁 ，所以事务B 在时间点5的时候执行 INSERT 操作的时候，出现了阻塞。
因为时间点5的 INSERT 操作被阻塞了，所以这次查询的数据跟时间点2的查询结果完全一致。
事务B想要执行 INSERT 成功，必须要等待事务A 提交事务释放锁，这就解决了幻读问题。

MVCC可以解决更新丢失问题吗？

MVCC 解决的是读写并发问题，而更新丢失是写写并发问题，MVCC不能解决更新丢失问题，更新丢失依赖数据库的隔离级别来解决。

如有不正确的地方请各位指出纠正。