mvcc深入

简介：
mvcc是通过undolog实现的，是multiversion concurrency control的简称，也就是多版本并发控制，是个很基本的概念。MVCC的作用是让事务在并行发生时，在一定隔离级别前提下，可以保证在某个事务中能实现一致性读，也就是该事务启动时根据某个条件读取到的数据，直到事务结束时，再次执行相同条件，还是读到同一份数据，不会发生变化（不会看到被其他并行事务修改的数据）。不需要通过加锁来解决，本质上维护了一个数据的多个版本，使得读写操作之间没有冲突。

工作在哪些隔离级别：
MVCC只在 READ COMMITTED和REPEATABLE READ两个隔离级别下工作。其他两个隔离级别够和MVCC不兼容,因为READ UNCOMMITTED总是读取最新的数据行,而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。

如何实现：
主要实现依靠undolog来实现，undolog里面会维护多个历史版本，包括一些隐藏字段
DB_TRX_ID(记录创建这条记录或者最后一次修改该记录的事务id)
DB_ROLL_PTR(回滚指针，指向上一个历史版本的状态)
DB_ROW_ID(隐藏主键，如果数据没有主键，innodb会生成一个6字节的rowid)

undolog实际上是一个链表，链首表示最新的旧记录，链尾是最早的旧记录。undolog不会无限扩展，server层会有一个purge线程来清理undolog中的数据。

read view
InnoDB MVCC使用的内部快照的意思。在不同的隔离级别下，事务启动时（有些情况下，可能是SQL语句开始时）看到的数据快照版本可能也不同。在RR、RC等几个隔离级别下会用到 read view。

简单理解，开启事务的时候，创建的快照版本，每个隔离级别创建的时间不一样，在可重复读RR隔离级别下，数据快照版本是在第一个读请求发起时创建的。在读已提交RC隔离级别下，则是在每次读请求时都会重新创建一份快照。

read view里面记录并维护的是事务信息，而不是数据信息，里面有三个重要的东西

trx_list(数值列表，表示在生成readview时刻当前系统的事务id)
up_limit_id(表示trx_list列表中事务id最小的值)
low_limit_id(readview生成时刻尚未分配的下一个事务id)

白话：
开始事务的时候，创建一个readview(快照)，这个readview是查询当前的活动事务，因为不能只有你一个人操作，所以有很多事务，而readview里面就是排好序的活动事务id，然后我当前的一个事务id(假设7)和readview(假设是8-10)里面的比较，如果是在左边，说明我的事务已经提交了，如果在右边或者在readview里面，就不能访问，就只能通过roll_pointer获取上一个版本的事务。(右边是在readview后面出现的，你当然不能访问，你当前readview只是当前的一个快照，怎么可能去访问快照后面的事务呢。再readview里面也是一样，活动事务，也不能访问)

如果是RR(可重复读)，只生成第一个readview，后续都是用的同一个readview，同一个readview的事务都是一样的，所以可以重复读，所以性能会高一点，使用同一个。第一次修改之后能看见，第二次修改还是前一次的数据
如果是RC(读已提交)，每次都重新生成一个readview。每次都是最新的事务，所以也叫做不可重复读
有什么用呢，如果是第一次readview，里面都是活动事务，假设第二次生成的时候，活动事务有提交了的事务。所以两次readview不一样了，所以读到的数据就会不一样了

可见性算法：