图解MVCC机制

Posted 2023-04-05

参考技术A

这个过程实际上会涉及到 脏写、脏读、不可重复读、幻读 ，四种问题。

mysql默认的事务隔离级别是RR（可重复读），而且 MySQL的RR级别是可以避免幻读发生 。也就是说，MySQL里执行的事务，默认情况下不会发生脏写、脏读、不可重复读和幻读的问题。

如何修改MySQL隔离级别？

Spring中默认隔离级别与MySQL一致，Spring中如何修改？

简单来说，就是执行一个事务的时候，就生成一个ReadView，里面比较关键的东西有4个：

示例：

通过undo log多版本链条，加上你开启事务时候生产的一个ReadView，然后再有一个查询的时候，根据ReadView进行判断的机制，你就知道你应该读取哪个版本的数据。

首先我们先要明白，多个事务并发运行的时候，同时读写一个数据，可能会出现脏写、脏读、不可重复读、幻读几个问题。

针对这些问题，所以才有RU、RC、RR和串行四个隔离级别。

然后MySQL实现MVCC机制的时候，是 基于undo log多版本链条+ReadView机制 来做的，默认的RR隔离级别，就是基于这套机制来实现的，依托这套机制实现了RR级别，除了避免脏写、脏读、不可重复读，还能避免幻读问题。因此一般来说我们都用默认的RR隔离级别就好了。

深入理解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机制详解

版本链比对规则：

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

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

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

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

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

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

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

   

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

4. 执行事务100的update account set name = \'lilei1\' where id = 1;

   

5. 执行事务100的update account set name = \'lilei2\' where id = 1;

6. 执行查询1的查询语句

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

   

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

7. 接着事务100提交

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

   

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

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

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

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

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

11. 事务200执行commit;

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

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

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

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

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

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

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