MVCC多版本并发控制机制

Mysql在可重复读隔离级别下如何保证事务较高的隔离性，，同样的sql查询语句在一个事务

里多次执行查询结果相同，就算其它事务对数据有修改也不会影响当前事务sql语句的查询结果。

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

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

 

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

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

这个版本链从下往上看。

可以保存下这张图进行查看。
 

---

一·表格第8行，select1执行sql。select name from account where id = 1;  

此时的版本链为

 此时的未提交事务id为100和200，最大事务id为300，所以readview:[100,200], 300 。

此时min_id为100，max_id为300，

 

先看版本链最上面一条，这个事务id为300，即trx_id 为300，看版本链比对规则，300在min_id <=trx_id<= max_id区间，然后300不在不在视图数组中，所以可见。所以查到的记录就是这条记录。

---

如果在可重复读隔离级别下，

二·表格第12行，

select1执行sql。select name from account where id = 1;  

此时的版本链为

 可重复读隔离级别下，同一个事务里面每次的readview是一样的，所以执行这条sql的时候readview还是[100,200], 300。

那现在从这条记录去比较（见下图），事务id 100是满足min_id <=trx_id<= max_id，同时满足trx_id 在视图数组中，所以不可见。

 继续比较下一条记录（见下图），事务id 100是满足min_id <=trx_id<= max_id，同时满足trx_id 在视图数组中，所以不可见。

 继续比较下一条记录（见下图），事务id 300是满足min_id <=trx_id<= max_id，300不在不在视图数组中，所以可见。所以查到的记录就是这条记录。

---

如果在可重复读隔离级别下，

三.表格第16行，

select1执行sql。select name from account where id = 1;  

此时的版本链为

 可重复读隔离级别下，同一个事务里面每次的readview是一样的，所以执行这条sql的时候readview还是[100,200], 300。

那现在从这条记录去比较（见下图），事务id 200是满足min_id <=trx_id<= max_id，同时满足trx_id 在视图数组中，所以不可见。

 再比较下一条（见下图），事务id 200是满足min_id <=trx_id<= max_id，同时满足trx_id 在视图数组中，所以不可见。

  再比较下一条（见下图），事务id 100是满足min_id <=trx_id<= max_id，同时满足trx_id 在视图数组中，所以不可见。

   再比较下一条（见下图），事务id 100是满足min_id <=trx_id<= max_id，同时满足trx_id 在视图数组中，所以不可见。

  继续比较下一条记录（见下图），事务id 300是满足min_id <=trx_id<= max_id，300不在不在视图数组中，所以可见。所以查到的记录就是这条记录。

---

结合readview和undo日志版本链去看，注意每次执行sql的时候都要看现在（此时此刻的）版本链里面的所有记录，然后从最新的一条开始做比对，知道找到一条可见的记录，就是要查询的结果。

在 可重复读隔离级别 ，当事务开启，执行任何查询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，意味着记录已被删除，则不返回数据。

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

总结：

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

解释：看到网上还有其他文章解释说max_id是最大事务id+1，其实和此处的判断逻辑一致，大于等于这个id+1的不可见，和大于这个id不可见一样。 比如>5和大于等于6是一样的。