什么是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–锁机制详解
#共享锁
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不能解决更新丢失问题，更新丢失依赖数据库的隔离级别来解决。
如有不正确的地方请各位指出纠正。
