一、定义

多版本控制: 指的是一种提高并发的技术。最早的数据库系统，只有读读之间可以并发，读写，写读，写写都要阻塞。引入多版本之后，只有写写之间相互阻塞，其他三种操作都可以并行，这样大幅度提高了InnoDB的并发度。在内部实现中，与Postgres在数据行上实现多版本不同，InnoDB是在undolog中实现的，通过undolog可以找回数据的历史版本。找回的数据历史版本可以提供给用户读(按照隔离级别的定义，有些读请求只能看到比较老的数据版本)，也可以在回滚的时候覆盖数据页上的数据。在InnoDB内部中，会记录一个全局的活跃读写事务数组，其主要用来判断事务的可见性。

二、数据库多版本读场景

session 1	session 2
select a from test; return a = 10
start transaction;
update test set a = 20;
	start transaction;
	select a from test; return ?
commit;
	select a from test; return ?

我们看下上面这个数据库日常操作的例子。

session 1修改了一条记录，没有提交；与此同时，session 2 来查询这条记录，这时候返回记录应该是多少呢？
session 1 提交之后 session 2 查询出来的又应该是多少呢？

由于MySQL支持多种隔离级别，这个问题是需要看session2的事务隔离级别的，情况如下:

隔离级别为 READ-UNCOMMITTED 情况下:
session 1 commit前后 session 2 去查看都会看到的是修改后的结果 a = 20
隔离级别为 READ-COMMITTED 情况下:
session 1 commit 前查看到的还是 a =10 , commit之后看到的是 a = 20
隔离级别为 REPEATABLE-READ， SERIALIZABLE 情况下:
session 1 commit前后 session 2 去查看都会看到的是修改后的结果 a = 10

其实不管隔离级别，我们也抛开数据库中的ACID，我们思考一个问题：众所周知，InnoDB的数据都是存储在B-tree里面的，修改后的数据到底要不要存储在实际的B-tree叶子节点，session2是怎么做到查询出来的结果还是10，而不是20列？