MVCC多版本并发控制机制学习随笔

MVCC多版本并发控制机制

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

这个隔离性就是靠MVCC(Multi-Version Concurrency Control)机制来保证的。

对一行数据的读和写两个操作在可重复读的隔离级别，默认是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥，而在串行化隔离级别为了保证较高的隔离性是通过将所有操作加锁互斥来实现的。

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

undo日志版本链和read view机制

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

事务修改一次，就会生成一条回滚日志记录。

在可重复读隔离级别，当事务开启，执行任何查询sql时会生成当前事务的一致性视图read-view，该视图在事务结束之前永远都不会变化。一个事务就有一个一致性视图read-view

如果是读已提交隔离级别在每次执行查询sql时都会重新生成read-view，一次查询就有一个一致性视图。

这个视图由执行查询时所有未提交事务id数组（数组里最小的id为min_id）和已创建的最大事务id（max_id）组成，事务里的任何sql查询结果需要从对应版本链里的最新数据开始逐条跟read-view做比对从而得到最终的快照结果。

由视图和每条日志去做比较，看哪条日志的改动对于当前视图可见，哪条改动对于当前视图不可见，从而实现了隔离级别

版本链比对规则：

1. 如果 row 的 trx_id 落在绿色部分( trx_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 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。

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

关于readView和可见性算法的理解

undolog会记录一行数据的每次历史操作，可以用来做回滚，也可以用来判断可见性从而实现隔离级别。

readview和可见性算法其实就是记录了sql查询那个时刻，数据库里哪些数据的修改是可见的，哪些数据的修改是不可见的。

如果想实现可重复读的隔离级别，事务中的每次查询都需要用一个唯一的readView去undo日志版本链中做对比，也就是都是以第一次查询时生成的readView，来比对数据是否可见，当然可以实现每次查询的可重复读的效果了

如果想实现读已提交的隔离级别，事务里每次执行查询操作，readview都会重新生成一份，都会按照数据库当前状态重新生成readview，也就是每次查询都是跟数据库里当前所有事务提交状态来比对数据是否可见，当然实现的就是每次都能查到已提交的最新数据效果了

注意：start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个修改操作或加排它锁操作(比如select...for update)的语句，事务才真正启动，才会向mysql申请真正的事务id，mysql内部是严格按照事务的启动顺序来分配事务id的。

总结：

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