1、MVCC概念讲解

数据多版本(MVCC，Multi-Version Concurrency Control)是MySQL实现高性能的一个主要方式。我们在上节课已经演示过：在“可重复读”隔离级别下，同一个Sql在一个事务里，多次查询到的结果是一样的， 就算其它事务对数据有修改也不会影响当前事务sql语句的查询结果。 这个隔离性就是靠MVCC(Multi-Version Concurrency Control)机制来保证的， 对一行数据的读和写两个操作默认是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥。 Mysql在读已提交和可重复读隔离级别下都实现了MVCC机制。 

  1.  先解释几个概念：

隐藏列

image.png
在InnoDB中，每一行都有几个个隐藏列：
Row_id：没有主键时,因为MYSQL默认聚簇表,会自动生成一个ROWID
DATA_TRX_ID：表示最近修改该行数据的事务ID
DATA_ROLL_PTR：指向写到rollback segment（回滚段）的一条undo log记录
整个MVCC的关键就是通过DATA_TRX_ID和DATA_ROLL_PTR这两个隐藏列来实现的。

undo日志版本链

undo日志版本链是指一行数据被多个事务依次修改过后，在每个事务修改完后，Mysql会保留修改前的数据undo回滚 日志，并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链，如图：
image.png

ReadView

ReadView说白了就是一个数据结构，在查询SQL开始的时候被创建。这个视图由执行查询时所有未提交事务id数组（数组里最小的id为min_id）和已创建的最大事务id（max_id）组成。
在可重复读隔离级别，当事务开启，执行任何查询sql时会生成当前事务的一致性视图read-view，该视图在事务结束 之前都不会变化；
在读已提交隔离级别在每次执行查询sql时都会重新生成；

版本链比对规则：

1、如果 row 的 trx_id 落在绿色部分( trx_id2、如果 row 的 trx_id 落在红色部分( trx_id>max_id )，表示这个版本是由将来启动的事务生成的，是不可见的(当前自己的事务可见）；
3、如果 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id)，那就包括两种情况
a. 若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(当前自己的事务可见)；
b. 若 row 的 trx_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。


对于删除的情况可以认为是update的特殊情况，会将版本链上最新的数据复制一份，然后将trx_id修改成删除操作的trx_id，同时在该条记录的头信息（record header）里的（deleted_flag）标记位写上true，来表示当前记录已经被删除，在查询时按照上面的规则查到对应的记录如果delete_flag标记位为true，意味着记录已被删除，则不返回数据。

MVCC机制的实现就是通过read-view机制与undo版本链比对机制，使得不同的事务会根据数据版本链对比规则读取 同一条数据在版本链上的不同版本数据。

2、MVCC机制实战演示

理论部分晦涩难懂，为了更好地了解MVCC机制，我们实际来操作感受一下。其实我们在上一节讲“可重复读”隔离级别时已经演示过，关键就要记住，在同一个事务里，一条数据被多次查询，结果是一样的，靠的就是MVCC机制。

下面的例子提供了操作步骤，以及操作的日志版本链，查询的结果可以自己按照版本链比对规则走一遍。

原始数据：
image.png
操作步骤
image.png
image.png


3、BufferPool缓存机制

注意：对于开发人员来说，这个知识点了解即可，不需要深入研究。

BufferPool缓存机制如下：
image.png
为什么Mysql不能直接更新磁盘上的数据而且设置这么一套复杂的机制来执行SQL了？
因为来一个请求就直接对磁盘文件进行随机读写，然后更新磁盘文件里的数据性能可能相当差。
因为磁盘随机读写的性能是非常差的，所以直接更新磁盘文件是不能让数据库抗住很高并发的。
Mysql这套机制看起来复杂，但它可以保证每个更新请求都是更新内存BufferPool，然后顺序写日志文件，同时还能保证各种异常情况下的数据一致性。
更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件。
正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几干甚至上万的读写请求。