MySQL高级学习笔记（七）

InnoDB中的多版本并发控制（MVCC）

MVCC (Multiversion Concurrency Control),多版本并发控制。 顾名思义, MVCC是通过数据行的多个版本管理来实现数据库的并发控制。这项技术使得在InnoDB的事务隔离级别下执行一致性读操作有了保证。换言之,就是为了查询一些正在被另一个事务更新的行,并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。

脏读、不可重复读、幻读这些并发问题除了可以利用锁机制来解决，另一个解决方式就是利用MVCC进行解决。

1.快照读和当前读

• 快照读又叫一致性读，读取的是快照数据。不加锁的简单的SELECT都属于快照读，即不加锁的非阻塞读;
• 当前读读取的是记录的最新版本(最新数据，而不是历史版本的数据)，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。加锁的SELECT，或者对数据进行增删改都会进行当前读。

2. MVCC的实现原理

MVCC的实现依赖于:行记录中的隐藏字段（trx_id，roll_pointer）、Undo Log、Read View。

• ReadView

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

• ReadView 的结构

使用READ COMNITTED 和REPEATABLE READ 隔离级别的事务,都必须保证读到已经提交了的事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交,是不能直接读取最新版本的记录的，核心问题就是需要判断 一下und olog版本链(roll_pointer这个隐藏字段指向undo日志的一个链表)中的哪个版本是当前事务可见的，这是ReadVew要解决的主要问题。

ReadView中主要包含4个比较重要的内容，分别如下:

1. creator_trx_id,创建这个Read View的事务ID。
   说明:只有在对表中的记录做改动时(执行INSERT、 DELETE、 UPDATE这些语句时) 才会为事务分配事务id，且这个事务id是递增的，否则在一个只读事务中的事务id值都默认为0。
2. trx_ids,表示在生成Read View时当前系统中活跃的读写事务的事务id列表。
3. up_limit_id,活跃的事务中最小的事务ID.
4. low_limit_id,表示生成Read View时系统中应该分配给下一个事务的id值。low_limit_id 是系统最大的事务id值，这里要注意是系统中的事务id,需要区别于正在活跃的事务ID。
   注意: low_limit_id并不是trx_ids中的最大值，事务id是递增分配的。比如，现在有id为1, 2，3这三个事务，之后id为3的事务提交了。那么一个新的读事务在生成Read View时，trx_ids就只包括1和2，up_limit_id的值就是1，而low_limit_id的值就是4(=3+1)。

• Read view 的规则

有了这个Read View，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见。

• 如果被访问版本的trx_id属性值与Read View中的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整体操作流程

我们来看下当查询一条记录的时候， 系统如何通过MVCC找到它

1. 首先获取事务自己的版本号，也就是事务ID;
2. 获取ReadView;
3. 查询得到的数据，然后与ReadView中的事务版本号进行比较;
4. 如果不符合ReadView规则，就需要从Undo Log中获取历史快照;
5. 最后返回符合规则的数据。

如果某个版本的数据对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断可见性，依此类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记录对该事务完全不可见，查询结果就不包含该记录。

1. 在隔离级别为读已提交(Read Committed)时，一个事务中的每一次SELECT查询都会重新获取一次Read View，这样是为了保证在读已提交的隔离级别下会产生的不可重复读和幻读问题会出现，因为读已提交隔离级别没有解决这两个问题。
2. 当隔离级别为可重复读的时候，就避免了不可重复读,这是因为一个事务只在第一次 SELECT的时候会获取一次Read View，而后面所有的SELECT都会复用这个Read View

• MVCC解决的问题

1. 读写之间阻塞的问题。 通过MVCC可以让读写互相不阻塞，即读不阻塞写，写不阻塞读，这样就可以提升事务并发处理能力。
2. 降低了死锁的概率。这是因为MVCC采用了乐观锁的方式，读取数据时并不需要加锁，对于写操作也只锁定必要的行。
3. 解决快照读的问题。 当我们查询数据库在某个时间点的快照时，只能看到这个时间点之前事务提交更新的结果，而不能看到这个时间点之后事务提交的更新结果。