MVCC详解

一、MVCC实现机制

链接: link. mvcc

https://www.cnblogs.com/mengxinJ/p/14045520.html 一条sql的执行步骤

2、MVCC的实现原理

MVCC的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖记录中的 3个隐式字段，undo日志 ，Read View 来实现的。
每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID等字段
DB_TRX_ID
6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID
DB_ROLL_PTR
7byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment里）
DB_ROW_ID
6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引
实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除flag变了

核心原理：我们知道 Read View主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个Read View读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。

Read View遵循一个可见性算法，主要是将要被修改的数据的最新记录中的DB_TRX_ID（即当前事务ID）取出来，与系统当前其他活跃事务的ID去对比（由Read View维护），如果DB_TRX_ID跟Read View的属性做了某些比较，不符合可见性，那就通过DB_ROLL_PTR回滚指针去取出Undo Log中的DB_TRX_ID再比较，即遍历链表的DB_TRX_ID（从链首到链尾，即从最近的一次修改查起），直到找到满足特定条件的DB_TRX_ID, 那么这个DB_TRX_ID所在的旧记录就是当前事务能看见的最新老版本

作者：爱情小傻蛋
链接：https://www.jianshu.com/p/8845ddca3b23
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

read view重的核心数据

trx_list（名字我随便取的）
一个数值列表，用来维护Read View生成时刻系统正活跃的事务ID
up_limit_id
记录trx_list列表中事务ID最小的ID
low_limit_id
ReadView生成时刻系统尚未分配的下一个事务ID，也就是目前已出现过的事务ID的最大值+1
当一个事务获取一条数据的时候首先获取到read view（不同的隔离级别获取的时机不同）然后获取到当前数据的DB_TRX_ID（当前数据的事务id，也就是最后一次插入或者修改该记录的事务id）

1.首先比较DB_TRX_ID < up_limit_id, 如果小于，则当前事务能看到DB_TRX_ID 所在的记录，如果大于等于进入下一个

2.判断接下来判断 DB_TRX_ID 大于等于 low_limit_id , 如果大于等于则代表DB_TRX_ID 所在的记录在Read View生成后才出现的，那对当前事务肯定不可见，如果小于则进入下一个判断

3. up_limit_id <DB_TRX_ID<low_limit_id 判断DB_TRX_ID 是否在活跃事务之中，trx_list.contains(DB_TRX_ID)，如果在，则代表我Read View生成时刻，你这个事务还在活跃，还没有Commit，你修改的数据，我当前事务也是看不见的
4. up_limit_id <DB_TRX_ID<low_limit_id 判断DB_TRX_ID 是否在活跃事务之中，trx_list.contains(DB_TRX_ID)，如果在 如果不在，则说明，你这个事务在Read View生成之前就已经Commit了，你修改的结果，我当前事务是能看见的

对于不同隔离级别下以上三种所表现出的效果

	可重复读	读已提交
第一种情况	因为当前数据的事务id 一定不会是在当前事务生成的read view 之后生成的（up_limit_id <low_limit_id ），所以这条数据一定是 在当前事务生成read view 之前最新更改或者新增的数据的事务id（原理同一）	因为每次获取的都是最新的read view 所以当前的数据一定是最新
第二种情况	当前的事务id大于 read view中的最大事务 当前记录是在第一次读取之后生成的不可见	因为每次读取的都是最新的read view 而low_limit_id又等于当前生成时刻系统尚未分配的下一个事务ID 所以这种情况不会存在
第三种情况	因为当前事务在生成read view时 DB_TRX_ID事务还在活跃中 并未提交所以当前事务看不到 这个时候会通过DB_ROLL_PTR 回滚指针 找到redo log中的上一条记录 重复执行read view的判断	因为每次读取的都是最新的read view 所以不可能存在一个事务id既在当前数据的事务id 又在活跃事务id里面 所以这种情况不会存在
第三种情况	因为当前事务在生成read view时 DB_TRX_ID事务还在活跃中 并未提交所以当前事务看不到 这个时候会通过DB_ROLL_PTR 回滚指针 找到redo log中的上一条记录 重复执行read view的判断	因为每次读取的都是最新的read view 所以不可能存在一个事务id既在当前数据的事务id 又在活跃事务id里面 所以这种情况不会存在
第四种情况	因为当前数据的事务id 一定不会是在当前事务生成的read view 之后生成的（up_limit_id <low_limit_id ），所以这条数据一定是 在当前事务生成read view 之前最新更改或者新增的数据的事务id（原理同一）	每次获取最新并且还不在活跃事务id 里面 所以该数据一定是 当前事务生成read view最新来记录

RC每次读取生成新的read view ,RR（同一个事务只会生成一次 后面读取都用前面的）