Mysql隔离级别MVCC多版本并发控制机制
欢迎大家关注我的微信公众号：
传送门：Mysql事务原理与优化
目录
概述
undo日志版本链与read view机制详解
深入浅出分析MVCC可见性算法的操作示例
关于readview和可见性算法的原理解释
总结
概述
在之前的文章中讲过，Mysql在可重复读隔离级别下，同样的sql查询语句在一个事务里多次执行查询结果相同，就算其它事务对数据有修改也不会影响当前事务sql语句的查询结果。
这个隔离性就是靠MVCC(Multi-Version Concurrency Control)机制来保证的，对一行数据的读和写两个操作默认是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥，而在序列化隔离级别为了保证较高的隔离性是通过将所有操作加锁互斥来实现的。
Mysql在读已提交(RC)和可重复读(RR)隔离级别下都实现了MVCC机制。本文通过案例来详细分析MVCC机制是如何实现的。
undo日志版本链与read view机制详解
undo log版本链
undo日志版本链是指一行数据被多个事务依次修改过后，在每个事务修改完后，Mysql会保留修改前的数据undo回滚日志，并且用两个隐藏字段trx_id(事务id)和roll_pointer(回滚指针)把这些undo日志串联起来形成一个历史记录版本链（见下图）。
当新增一条数据时，会生成一个insert undo log，里面会有对应的一条delete语句。回滚指针roll_pointer会指向insert undo log。当insert事务回滚时，通过roll_pointer找到insert undo log并执行对应的delete语句，完成回滚操作。当对同一条数据不断update时，会在每次update后都生成一条新的undo log，并且每条新数据中的roll_pointer都指向修改前的数据，用于回滚update操作。
一致性视图read-view
在可重复读隔离级别，当事务开启，执行任何查询sql时会生成当前事务的一致性视图read-view，该视图在事务结束之前永远都不会变化(如果是读已提交隔离级别在每次执行查询sql时都会重新生成read-view)，这个视图由执行查询时所有未提交事务id数组（数组里最小的id为min_id）和已创建的最大事务id（max_id）组成，事务里的任何sql查询结果需要从对应版本链里的最新数据开始逐条跟read-view做比对，从而得到最终的快照结果。
- 如果 row 的 trx_id 落在绿色部分( trx_id
可见的； - 如果 row 的 trx_id 落在红色部分( trx_id>max_id )，表示这个版本是由将来启动的事务生成的，是不可见的(若 row 的trx_id 就是当前自己的事务是可见的）；
- 如果 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id)，那就包括两种情况：
a. 若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 trx_id 就是当前自己的事务是可见的)；
b. 若 row 的 trx_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。
深入浅出分析MVCC可见性算法的操作示例
RR隔离级别MVCC可见性算法示例（上图中从上到下依次执行）：
1、由update test表sql语句开启trx_id=100的事务，再由update test表sql语句开启trx_id=200的事务。然后开始操作account表，设balance初始值为0，执行update account set balance = balance+500 where id=1，开启trx_id=300的事务，并commit提交。此时数据库真实结果为500。
2、开始查询事务select1，执行select balance from account where id=1，查询结果是500。
结果分析：根据read-view生成规则【由执行查询时所有未提交事务id数组（数组里最小的id为min_id）和已创建的最大事务id（max_id）组成】，此时100和200均未提交，最大的事务id为300，因此此时的read-view一致性视图为：[100,200]300。然后我们通过undo log版本链来逐条与read-view对比：首先拿到提交的最新数据balance=500，当前的trx_id=300，根据版本链对比规则，300在区间(min_id <=trx_id<= max_id)中，并且对应b规则，不在视图数组中，表示这个版本是已经提交了的事务生成的，是可见的，因此查询出的结果是500。
3、然后由事务100执行update account set balance = balance+300 where id=1，再次执行update account set balance = balance+200 where id=1，（同时undo日志链中生成2条undo log）并commit提交。总共增加了500，此时数据库的真实结果变为1000。
4、仍然在查询事务select1下，再次执行select balance from account where id=1，查询结果还是500。这就是RR隔离级别的可重复读。
结果分析：因为当事务开启，执行任何查询sql时会生成当前事务的一致性视图read-view，该视图在事务结束之前永远都不会变化，所以在事务select1下，此时的read-view一致性视图仍然为：[100,200]300，根据版本链比对规则，首先拿到提交的最新数据balance=1000，trx_id=100,100在区间(min_id <=trx_id<= max_id)中，并且对应a规则，在视图数组中，表示这个版本是由还没提交的事务生成的，是不可见的。因此通过roll_pointer找到上一条，trx_id=100，还是不可见，就继续找到上一条。此时trx_id=300，在区间(min_id <=trx_id<= max_id)中，并且对应b规则，不在视图数组中，是可见的，因此查询到的结构仍然是500。
5、然后我们新开启一个事务select2，执行select balance from account where id=1，此时查询结果变成了1000。
结果分析： 由于是新开启的事务，所以会重新生成一个read-view。此时事务100已提交，事务200未提交，事务300最大，因此read-view一致性视图为：[200]300。还是按照上述规则进行比对，首先拿到最新的结果balance=1000，trx_id=100，在区间( trx_id
6、然后由事务200执行update account set balance = balance+500 where id=1，再次执行update account set balance = balance+300 where id=1，（同时undo日志链中生成2条undo log）并commit提交。总共增加了800，此时数据库的真实结果变为1800。
7、在事务select1和事务select2下分别执行select balance from account where id=1，查询结果与之前一致，分别为500和1000。这里不再赘述，大家可以根据undo log版本链对比规则自己验算一下。
注意：对于删除的情况可以认为是update的特殊情况，会将版本链上最新的数据复制一份，然后将trx_id修改成删除操作的trx_id，同时在该条记录的头信息（record header）里的（deleted_flag）标记位写上true，来表示当前记录已经被删除，在查询时按照上面的规则查到对应的记录如果delete_flag标记位为true，意味着记录已被删除，则不返回数据。
关于readview和可见性算法的原理解释
readview和可见性算法其实就是记录了sql查询那个时刻数据库里提交和未提交所有事务的状态。
要实现RR隔离级别，事务里每次执行查询操作readview都是使用第一次查询时生成的readview，也就是都是以第一次查询时当时数据库里所有事务提交状态来比对数据是否可见，当然可以实现每次查询的可重复读的效果了。
要实现RC隔离级别，事务里每次执行查询操作readview都会按照数据库当前状态重新生成readview，也就是每次查询都是跟数据库里当前所有事务提交状态来比对数据是否可见，当然实现的就是每次都能查到已提交的最新数据效果了。
注意：begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个修改操作或加排它锁操作(比如select...for update)的语句，事务才真正启动，才会向mysql申请真正的事务id，mysql内部是严格按照事务的启动顺序来分配事务id的（事务id是递增的）。
总结
MVCC机制的实现就是通过read-view机制与undo log版本链比对机制，使得不同的事务会根据数据版本链对比规则读取同一条数据在版本链上的不同版本数据。