深入理解MVCC与BufferPool缓存机制

目录

MVCC多版本并发控制机制

举例说明

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

版本链举例

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

其他


MVCC多版本并发控制机制

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

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

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

我的理解:如果在可重复读的情况下,你查询的数据是历史版本,这个事务执行的时候读取到的数据库数据都是历史数据,如果该事务未提交,数据库中的数据如何更改,你读取的都是执行select的时候数据库实际的数据,后面读到的也都是这个数据,这个是读,如果是修改的话update,那是基于数据库最新的数据进行修改的

举例说明

  • 刚开始数据库id=1实际数据为450,然后我开启事务查询显示450
  • 然后我把数据库id=1的数据改为了400,在这个事务中我查询依然是450,证明是可重复读隔离级别
  • 然后,我进行了修改操作,将id=1的数据减掉50,可以看到结果为350,是按照数据库里面的实际结果进行操作的

下面就解释如何实现的MVCC机制

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

undo日志版本链是指一行数据被多个事务依次修改过后,在每个事务修改完后,Mysql会保留修改前的数据undo回滚日志,并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链(见下图,需参考视频里的例子理解) 

我的理解,就是一行数据被多个事务进行修改,每次修改之后会生成一条undo日志,日志中里包含trx_id和roll_pointer两个隐藏字段,roll_pointer会指向之前的事务修改日志,通过指针和undo串联起来形成日志版本链

在可重复读隔离级别,当事务开启,执行任何查询sql时会生成当前事务的一致性视图read-view,该视图在事务结束之前都不会变化(如果是读已提交隔离级别在每次执行查询sql时都会重新生成),这个视图由执行查询时所有未提交事务id数组(数组里最小的id为min_id)和已创建的最大事务id(max_id)组成,事务里的任何sql查询结果需要从对应版本链里的最新数据开始逐条跟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 不在视图数组中,表示这个版本是已经提交了的事务生成的,可见。       

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

版本链举例

100、200、300同时执行,300已经执行完毕, 100、200是正在执行事务,select 1里面开始执行查询操作,开始生成readview,这个视图会在你commit之前都不会发生变化的,未提交数组和最大id组成,那这样就是[100,200],300这个样子,我们从版本链最新的数据读起,最新版本是100或者200,然后接着是300,100和200落在数组中,不可见,300落在数组外面是可见的,所以读300的数据

总结:

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

如果是读已提交隔离级别,也是MVCC机制但是是按照另一套逻辑来处理的

readview都是针对当前事务生成的,是在你实际查询的时候生成的,不是你begin的时候生成的,是针对整个数据库的,你单独查另一张表b,然后在a表进行修改,再次去查a表的数据,显示的是修改前的数据,针对这个时候select会生成readreview
 

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

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

其他

  • ACID就是为了我们写代码方便,如果数据总是变动,这样很麻烦,没办法写代码 
  • 串行化是加锁,用到的相同数据,串行执行,整张表的所有数据加锁,数据插不进来,他是针对你查询的sql语句加锁,你查出几条记录就加哪几条记录的锁,对你操作的数据加锁,操作的数据不能动,比如你查id为1的数据,或者你插入id为6的数据,这两个数据如果在事务中的话,其他线程是对这两条数据不能操作的,阻塞中
  • 串行化效率低
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值