MVCC底层原理与Mysql日志详解

  作者:图灵javaer


在线预览


MVCC多版本并发控制机制


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


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


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


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


undo日志版本链是指一行数据被多个事务依次修改过后,在每个事务修改完后,Mysql会保留修改前的数据undo回滚日志,为了在修改数据时,万一没改成功,就回滚数据。




并且用两个隐藏字段trx_idroll_pointer把这些undo日志串联起来形成一个历史记录版本链




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



注意:begin/start transaction 命令并不是一个事务的起点在执行到它们之后的第一个修改操作InnoDB表的语句,事务才真正启动,才会向mysql申请事务idmysql内部是严格按照事务的启动顺序来分配事务id的。


MVCC机制举例


MVCC机制举例.xlsx


可重复读隔离级别下:

第一条查询sql语句生成之后,readview一致性视图在之后的查询都不会改变


select 1




select 2




已提交读隔离级别下:

每次查询sql语句生成之后,readview一致性视图在之后的查询都都会根据当前数据库的数据做改变


select 1




select 2





版本链比对规则:




  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,意味着记录已被删除,则不返回数据。


总结:


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


示例一:


初始数据(InnoDB表):



1、开启事务


    


2、会话1 执行第一条sql查询语句


       


3、修改数据




4、会话1 再次执行sql查询语句,会话2 执行sql查询语句


       


发现会话1查询数据没有发生改变,而会话2的查询数据已经变为最新更新的数据。


示例二:


初始数据(InnoDB表):



1、开启事务


    


2、会话1 执行第一条sql查询语句(InnoDB表)




3、修改数据


4、会话1 再次执行sql查询语句,会话2 执行sql查询语句


     


发现即使是不同表的查询语句,会话1查询数据也没有发生改变,而会话2的查询数据已经变为最新更新的数据。


结论:

每个事务都有自己专属的readview视图,后面进行的查询操作都是基于当前事务的readview,当前查询的结果集是根据每个事务自己的readview视图到undo版本链中进行比对得到的,undo版本链只有一份,而readview视图是每个事务都会带有一份


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




执行更新语句


update t set name = "zhuge666" where id = 1;

id 为 1 的 name 原始值为 zhuge


1、加载缓存数据,加载id为1的记录所在的整页数据(默认大小16kb)到Buffer Pool缓存池





2、写入更新数据的旧值便于回滚


如果事务提交失败要回滚数据, 可以用undo日志里的数据恢复 buffer pool里的缓存数据


3、更新内存数据


4、写redo日志


redo日志和binlog日志内容差不多,不过redo日志是恢复Buffer Pool缓存池中的数据,而binlog是恢复磁盘ibd数据


5、准备提交事务,redo日志写入数据


6、准备提交事务,blnlog日志写入数据


binlog日志是在server层,所有存储引擎都有的,而undo日志和redo日志InnoDB引擎特有的。


7、写入commit标记到redo日志文件里,提交事务完成,该标记为了保证事务提交后 redo与binlog数据一致


8、后台IO线程随机写入磁盘,以page为单位写入,这步做完磁盘里的name=zhuge666


redo日志的作用


如果事务提交成功, buffer pool里的数据还没来得及写入磁盘,此时系统宕机了,可以用redo日志里的数据恢复buffer pool里的缓存数据


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


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


相关推荐

评论 抢沙发

表情

分类选择