深入理解MVCC与BufferPool缓存机制

深入理解MVCC与BufferPool缓存机制 MVCC多版本并发控制机制

Mysql在可重复读隔离级别下如何保证事务较高的隔离性，我们上节课给大家演示过，同样的sql查询语句在一个事务 里多次执行查询结果相同，就算其它事务对数据有修改也不会影响当前事务sql语句的查询结果。

这个隔离性就是靠MVCC(Multi-Version Concurrency Control)机制来保证的，对一行数据的读和写两个 *** 作默认 是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥，而在串行化隔离级别为了保证较高的隔离性是通过将所有 *** 作加锁互斥来实现的。

Mysql在读已提交和可重复读隔离级别下都实现了MVCC机制。

在可重复读隔离级别，当事务开启，执行任何查询sql时会生成当前事务的一致性视图read-view，该视图在事务结束 之前都不会变化(如果是读已提交隔离级别在每次执行查询sql时都会重新生成)，这个视图由执行查询时所有未提交事 务id数组（数组里最小的id为min_id）和已创建的最大事务id（max_id）组成，事务里的任何sql查询结果需要从对应 版本链里的最新数据开始逐条跟read-view做比对从而得到最终的快照结果。

undo日志版本链与read view机制详解

版本链比对规则：

如果 row 的 trx_id 落在绿色部分( trx_id < min_id）,表示这个版本是已提交的事务生成的，这个数据是可见的；

如果 row 的 trx_id 落在红色部分( trx_id>max_id )，表示这个版本是由将来启动的事务生成的，是不可见的(若 row 的 trx_id 就是当前自己的事务是可见的）

如果 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id)，那就包括两种情况

a.若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 trx_id 就是当前自 己的事务是可见的)；

b.若 row 的 trx_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。

一开始事务100、事务200、事务300和查询1都开启；

先执行事务100的update语句，然后执行事务200的更新语句，然后执行事务300的更新语句和commit语句。

执行查询1的语句，执行结果readview[100,200],300 lilei300

执行事务100的update account set name = ‘lilei1‘ where id = 1;

执行事务100的update account set name = ‘lilei2‘ where id = 1;

执行查询1的查询语句

这个时候我们查询的时候，需要结合我们一开始的那张图和版本链比对规则，我将它贴到下面：

如上图，我们查询的时候，先从上面开始，trx_id为100，落在黄色部分，而且这个事务100还没有提交，所以不可见，然后往下找，同样，也不可见，继续往下找，trx_id为300，落在了红色部分，所以可见，也即lilei300

接着事务100提交

接着执行事务200的更新语句

然后执行事务200的更新语句

然后执行查询1的查询语句

? 首先从最上面开始查找，trx_id为200，在黄色部分，而且此时事务200未提交，所以是不可见的；

? 然后向下查找，trx_id为200，继续向下查找；

? 然后向下查找，trx_id为100，在绿色部分，是可见的，所以是lilei2

事务200执行commit;

Innodb引擎SQL执行的BufferPool缓存机制

为什么Mysql不能直接更新磁盘上的数据而且设置这么一套复杂的机制来执行SQL了？

因为来一个请求就直接对磁盘文件进行随机读写，然后更新磁盘文件里的数据性能可能相当差

因为磁盘随机读写的性能是非常差的，所以直接更新磁盘文件是不能让数据库抗住很高并发的。

Mysql这套机制看起来复杂，但它可以保证每个更新请求都是更新内存BufferPool，然后顺序写日志文件，同时还能 保证各种异常情况下的数据一致性。

更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件。

正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几干的读写请求。

深入理解MVCC与BufferPool缓存机制