目录
一、快照读与当前读
1.1 快照读
1.1 当前读
二、隐藏字段与Undo Log版本链
三、ReadView
3.1 概念
3.2 结构
3.3 规则
四、MVCC流程
五、举例
MVCC （Multiversion Concurrency Control），多版本并发控制。顾名思义，MVCC 是通过数据行的多个版本管理来实现数据库的并发控制 。这项技术使得在InnoDB的事务隔离级别下执行 一致性读操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。MVCC的实现依赖于隐藏字段、Undo Log、Read View。
一、快照读与当前读
MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理 读-写冲突 ，做到即使有读写冲突时，也能做到不加锁 ， 非阻塞并发读 ，而这个读指的就是快照读 , 而非 当前读 。当前读实际上是一种加锁的操作，是悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。
1.1 快照读
一致性读，读取的是快照数据（历史数据）。不加锁的简单 SELECT 都属于快照读，即不加锁的非阻塞读。之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于MVCC，它在很多情况下， 避免了加锁操作，降低了开销。
多版本，那么快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。
SELECT * FROM player WHERE ...1.1 当前读
当前读读取的是记录的最新版本（最新数据，而不是历史版本的数据），读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。加锁的 SELECT，或者对数据进行增删改都会进行当前读。
SELECT * FROM student LOCK IN SHARE MODE; # 共享锁
SELECT * FROM student FOR UPDATE; # 排他锁
INSERT INTO student values ... # 排他锁
DELETE FROM student WHERE ... # 排他锁
UPDATE student SET ... # 排他锁二、隐藏字段与Undo Log版本链
对于使用 InnoDB 存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列。
trx_id ：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的 事务id 赋值给 trx_id 隐藏列。
roll_pointer ：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到 undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。
假如现在通过id为8的事务T1插入一条名字为“张三”的数据。
之后两个事务id分别为 10 、 20 的事务T2、T3对这条记录进行 UPDATE 操作，
每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个 roll_pointer 属性，可以将这些 undo日志 都连起来，串成一个链表：
随着更新次数的增多，所有的版本都会被 roll_pointer 属性连接成一个链表，我们把这个链表称之为 版本链 ，版本链的头节点就是当前记录最新的值。 每个版本中还包含生成该版本时对应的 事务id 。
三、ReadView
3.1 概念
ReadView就是用来确定读取数据历史记录中的哪一条的，是一个事务在使用MVCC机制进行快照读操作时产生的读视图。
READ COMMITTED 和 REPEATABLE READ 隔离级别的事务，都必须保证读到 已经提交了的事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本记录的，核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的，这是ReadView要解决的主要问题。
3.2 结构
ReadView中主要包含4个比较重要的内容，分别如下：
1. creator_trx_id ，创建这个 Read View 的事务 ID。
2. trx_ids ，表示在生成ReadView时当前系统中活跃的读写事务的事务id列表 。
3. up_limit_id ，活跃的事务中最小的事务 ID。
4. low_limit_id ，表示生成ReadView时系统应该分配给下一个事务的 id 值。low_limit_id 是系统最大的事务id值，这里要注意是系统中的事务id，需要区别于正在活跃的事务ID。事务id是递增分配的。
举例来说，trx_ids为trx2、trx3、trx5、trx8的集合，系统的最大事务ID（low_limit_id）为trx8+1，活跃的最小事务ID（up_limit_id）为trx2.
3.3 规则
有了ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见。
如果被访问版本的trx_id属性值与ReadView中的 creator_trx_id 值相同，意味着当前事务在访问 它自己修改过的记录，所以该版本可以被当前事务访问。
如果被访问版本的trx_id属性值小于ReadView中的 up_limit_id 值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。
如果被访问版本的trx_id属性值大于或等于ReadView中的 low_limit_id 值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。
如果被访问版本的trx_id属性值在ReadView的 up_limit_id 和 low_limit_id 之间，那就需要判断一下trx_id属性值是不是在 trx_ids 列表中。
如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问。 如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。
四、MVCC流程
当查询一条记录的时候：
1. 首先获取事务自己的版本号，也就是事务 ID；
2. 获取 ReadView；
3. 查询得到的数据，然后与 ReadView 中的事务版本号进行比较；
不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照；
符合规则的数据。
注：
在隔离级别为读已提交（Read Committed）时，一个事务中的每一次 SELECT 查询都会重新获取一次 Read View。在隔离级别为可重复读时，一个事务只获取一次Read View。
五、举例
读已提交的隔离级别。
现在有两个 事务id 分别为 10 、 20 的事务在执行：
# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...版本链表如下所示：
假设现在有一个使用 READ COMMITTED 隔离级别的事务开始执行：
# 使用READ COMMITTED隔离级别的事务
BEGIN;
# SELECT1：Transaction 10、20均未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
现在产生了一个ReadView，
creator_trx_id ：0
2. trx_ids ：[10,20]
3. up_limit_id :10
4. low_limit_id ：21
从上往下看，
‘王五’的事务id为10，在事务列表内，不符合规则；
‘李四’的事务id也为10，不符合规则；
‘张三’的事务id为8，小于up_limit_id，符合规则，返回此版本的记录。
之后，我们把 事务id 为 10 的事务提交一下，然后再到 事务id 为 20 的事务中更新一下表 student 中 id 为 1 的记录：
UPDATE student SET name="钱七" WHERE id=1;
UPDATE student SET name="宋八" WHERE id=1;此刻，表student中 id 为 1 的记录的版本链就长这样：
READ COMMITTED
# 使用READ COMMITTED隔离级别的事务
BEGIN;
# SELECT2：Transaction 10提交，Transaction 20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'王五'
现在产生了一个ReadView，
creator_trx_id ：0
2. trx_ids ：[20]
3. up_limit_id :20
4. low_limit_id ：21
从上往下看，
在活跃事务列表内，不符合规则；
’钱七‘的事务id也为20，在活跃事务列表内，不符合规则；
‘王五’的事务id为10，小于up_limit_id，符合规则，返回此版本的记录；
