基本简介

MVCC (Multiversion Concurrency Control)，多版本并发控制。顾名思义，MVCC是通过数据行的多个版本管理来实现数据库的并发控制。这项技术是为了查询一些正在被另一个事务更新的行，并且看到它们被更新之前的值，这样在做查询的时候就不用等待另—个事务释放锁。
MVCC没有正式的标准，在不同的DBMS中MVCC的实现方式可能是不同的，也不是普遍使用的(可以参考相关的DBMS文档)。这里说的是InnoDB中 MVCC的实现机制(MySQL其它的存储引擎并不支持它)。

快照读与当前读

MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，不阻塞 ，而这个读指的就是快照读 , 而非当前读。
当前读实际上是一种加锁的操作，是悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。

快照读

快照读又叫一致性读，读取的是快照数据。不加锁的简单的 SELECT 都属于快照读。

  1. SELECT * FROM player WHERE ...

之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于MVCC，它在很多情况下，避免了加锁操作，降低了开销。既然是基于多版本，那么快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。
快照读的前提是隔离级别不是串行级别(Serializable)，串行级别下的快照读会退化成当前读。

当前读

当前读读取的是记录的最新版本（最新数据，而不是历史版本的数据)，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。加锁的SELECT，或者对数据进行增删改都会进行当前读。

  1. SELECT * FROM student LOCK IN SHARE MODE;  # 共享锁
  3. SELECT * FROM student FOR UPDATE; # 排他锁
  5. INSERT INTO student values ...  # 排他锁
  7. DELETE FROM student WHERE ...  # 排他锁
  9. UPDATE student SET ...  # 排他锁

ReadView

基本简介

MVCC的实现依赖于：隐藏字段、Undo Log、Read View。在MVCC机制中，多个事务对同一个行记录进行更新会产生多个历史快照，这些历史快照保存在Undo Log里。如果一个事务想要查询这个行记录，需要读取哪个版本的行记录呢？这时就需要用到ReadView了，它帮我们解决了行的可见性问题。
ReadView就是事务在使用MVCC机制进行快照读操作时产生的读视图。当事务启动时，会生成数据库系统当前的一个快照，InnoDB为每个事务构造了一个数组，用来记录并维护系统当前活跃事务的ID(活跃指的就是，启动了但还没提交)。

设计思路

使用READ UNCONMITTED隔离级别的事务，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了。
使用SERIALIZABLE隔离级别的事务，InnoDB规定使用加锁的方式来访问记录。
使用 READ COMMITTED 和 REPEATABLE READ 隔离级别的事务，都必须保证读到已经提交了的事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的，这是ReadView要解决的主要问题。

主要内容

image.png
举例：trx_ids为 trx2、trx3、trx5和trx8的集合。则up_limit_id为trx2，low_limit_id为trx8+1。
image.png

规则

如果被访问版本的trx_id值与当前ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
如果被访问版本的trx_id值小于当前ReadView中的up_limit_id(最小事务)值，表明被访问版本在当前事务生成ReadView前已经提交，所以可以被当前事务访问。
如果被访问版本的trx_id值大于或等于ReadView中的low_limit_id(最大事务+1)值，表明被访问版本在当前事务生成ReadView后才开启，所以不可以被当前事务访问。
如果被访问版本的trx_id值在ReadView的up_limit_id和low_limit_id之间，那就需要判断—下trx_id属性值是不是在trx_ids列表中。
如果在，说明创建ReadView时(注意trx_ids里的事务有可能提交，但是还是在trx_ids中的)被访问版本的事务还是活跃的，不可以被访问。
如果不在，说明创建ReadView时被访问版本的事务已经被提交，可以被访问。

MVCC整体操作流程

image.png

隔离级别说明

READ COMMITTED隔离级别下

每次读取数据前都生成一个ReadView。

  1. #现在有两个事务：10和20
  2. #Transaction 10
  3. BEGIN;
  4. UPDATE student SET name="李四" WHERE id=1;
  5. UPDATE student SET name="王五" WHERE id=1;
  7. # Transaction 20
  8. BEGIN;
  9. UPDATE student SET name="钱七" WHERE id=1;
  10. UPDATE student SET name="宋八" WHERE id=1;
  13. #在READ COMMITTED下，另一个事务开始查询id=1的数据
  14. BEGIN;
  15. #Transaction 10、20未提交
  16. SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'（原数据）
  18. #Transaction 10提交了，而20还没有提交
  19. SELECT * FROM student WHERE id = 1; # 得到的列name的值为'王五'
  21. # 10和20都提交的时候
  22. SELECT * FROM student WHERE id = 1; # 得到的列name的值为'宋八'
  23. (说明每次查询都要生成一个ReadView)

image.png

REPEATABLE READ隔离级别下

只会在第一次执行查询语句时生成一个 ReadView ，之后的查询就不会重复生成了。

  1. #还是上一个例子的情况，另一个事务开始查询
  2. BEGIN;
  4. # Transaction 10、20未提交 (此时生成一个ReadView后，就再也不会改变了)
  5. SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
  7. # Transaction 10提交，Transaction 20未提交
  8. SELECT * FROM student WHERE id = 1; # 得到的列name的值仍为'张三'

解决幻读的问题

假设现在有一条数据，它的undo log如下图所示。同时现在有事务A(id=20)和事务B(id=30)在并发执行。
image.png
步骤一，事务A开始第一次查询数据：

  1. select * from student where id >= 1;

在开始查询之前，MySQL会为事务A产生一个ReadView，此时ReadView的内容如下：trx_ids = [20,30]，up_limit_id=20，low_limit_id=31，creator_trx_id=20。
此时表中这个数据符合条件，会被查询出来。然后根据ReadView机制，发现该行数据的trx_id=10，小于ReadView的up_limit_id，表示这条数据是事务A开启之前就已经提交的数据，因此可以读到。
步骤二，事务B往student表中插入两条新数据，并提交事务。

  1. insert into student(id,name) values(2,'李四');
  2. insert into student(id,name) values(3,'王五');
  3. #此时student表中就有三条数据了。

image.png
步骤三：事务A开启第二次查询，根据 可重复读隔离级别的规则，此时事务A不会再生成ReadView(还是第一次查询那个)。此时student的三条数据都符合条件，因此会被查出。
然后根据ReadView机制判断数据是否能被事务A看到：1. id=1，跟上面相同，能被看到。 2. id=2，它的trx_id=30，处于 up_limit_id和low_limit_id之间，因此继续判断30是否处于trx_ids数组内。由于事务A的trx_ids=[20,30]，30在trx_ids中，说明ReadView创建时，事务B还是活跃的，因此这条数据不能被事务A看到。 3. id=3，同理，不能被看到。