MVCC 机制

MVCC 多版本并发控制

1. 主要是在InnoDB存储引擎的读已提交RR和可重复读RR的事务模式下使用。
2. 解决了脏读、幻读、不可重复读问题。解决了读写、读读问题，但是解决不了写写问题。
依靠的是版本链、undo日志、Read View来实现的，在数据库中的表有三个隐藏列，分别是db_trx_id、db_poll_point、db_row_id、其实还有一个删除flag、数据被删除或者更新，不是真的被删除了，而是flag发生了改变。
1. db_trx_id代表的是当前的事务id。
2. db_poll_point代表是回滚指针，指向这条记录的上一版本，配合undo日志来使用。
3. db_row_id隐藏的主键id（自增）、如果数据表中没有主键的话，MySQL会自动产生一个隐藏的聚簇索引。
3. ReadView是一个快照读，（读视图），记录并维护当前活跃的事务id（即commit提交了，都会自动分配一个id，这个id是自增的，会越来越大），是系统中当前不应该被本事务看到的其他事务的列表。
4. undo日志，存放的记录被修改之前的日志，在表信息修改之前，会被数据拷贝到undolog中，当事务回滚时候，会undolog日志进行数据还原。

   • 保证事务进行回滚（rollback）时的原子性和一致性，当事务进行回滚的时候可以用undo log的数据进行恢复。

   • 用于MVCC快照读的数据，在MVCC多版本控制中，通过读取undo log的历史版本数据可以实现不同事务版本号都拥有自己独立的快照数据版本。

　　　　undolog主要分为两种，insert和update undolog。insert undolog，事务在insert的时候产生的undolog。只是在事务回滚的时候才被需要，事务提交之后立马删除。update undolog，事务在update和delete的时候产生的undolog，不仅在事务回滚的时候需要，在快照读的时候也需要，所以不能顺便删除，只有在快速读或者事务回滚不需要的时候，对应的日志才会被purge线程统一删除。

1. Read View主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个Read View读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。
2. ReadView 有几个属性分别介绍一下。trx_ids当前系统活跃(未提交)事务版本号集合。、low_limit_id创建当前read view 时“当前系统最大事务版本号+1”。、up_limit_id创建当前read view 时“系统正处于活跃事务最小版本号”、creator_trx_id创建当前read view的事务版本号；可见性的判断主要是

   db_trx_id< up_limit_id || db_trx_id == creator_trx_id 如果数据事务ID小于read view中的最小活跃事务ID，则可以肯定该数据是在当前事务启之前就已经存在了的,所以可以显示。或者数据的事务ID等于creator_trx_id ，那么说明这个数据就是当前事务自己生成的，自己生成的数据自己当然能看见，所以这种情况下此数据也是可以显示的。

 　　　db_trx_id > low_limit_id如果数据事务ID大于read view 中的当前系统的最大事务ID，则说明该数据是在当前read view 创建之后才产生的，所以数据不显示。如果小于则进入下一个判断　　

　　　 db_trx_id是否在活跃事务（trx_ids）中；不存在：则说明read view产生的时候事务已经commit了，这种情况数据则可以显示。已存在：则代表我Read View生成时刻，你这个事务还在活跃，还没有Commit，你修改的数据，我当前事务也是看不见的。