2.2 undo log

2.2.1 基本概念

undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。

作用：

        用于事务的回滚

                undo日志用于存放数据修改被修改前的值，如果这个修改出现异常，可以使用undo日志来实现回滚操作，保证事务的一致性。

                undo日志，只将数据库逻辑地恢复到原来的样子，在回滚的时候，它实际上是做的相反的工作

        用于MVCC

undo log的类型主要分为：

        insert undo log

        update undo log

2.2.2 insert undo log

insert undo log是指在insert 操作中产生的undo log，因为insert操作的记录，只对事务本身可见，对其他事务不可见。故该undo log可以在事务提交后直接删除，不需要进行purge操作。

2.2.3 update undo log

update undo log记录的是对delete 和update操作产生的undo log，该undo log可能需要提供MVCC机制，因此不能再事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。

具体工作原理需要分以下情况讨论

2.2.3.1 更新主键

聚簇索引和二级索引都无法进行in place update，都会产生两个版本

update分两步执行，先删除该行，再插入一行目标行

2.2.3.2 更新非主键

聚簇索引可以in place update，二级索引产生两个版本

聚簇索引记录undo log，二级索引不记录undo log

更新二级索引，同时需要判断是否修改索引页面的MAX_TRX_ID

2.2.3.3 删除操作

删除操作实际上不会直接删除，而只是标记为删除，最终的删除操作是purge线程完成的

2.2.4 purge线程两个主要作用是：

清理undo log

清除page里面带有Delete_Bit标识的数据行。在InnoDB中，事务中的Delete操作实际上并不是真正的删除掉数据行，而是一种Delete Mark操作，在记录上标识删除，真正的删除工作需要后台purge线程去完成。

2.3 Read View(读视图)

2.3.1 什么是Read View

Read View就是事务进行快照读操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID（当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以最新的事务，ID值越大）

2.3.2 作用

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

2.3.3 核心算法（可见性算法）

Read View的三个属性

trx_ids

        一个数值列表，用来维护Read View生成时刻系统正活跃的事务ID

up_limit_id

        记录trx_ids列表中事务ID最小的ID

low_limit_id

        ReadView生成时刻系统尚未分配的下一个事务ID，也就是目前已出现过的事务ID的最大值+1

可见性判断的流程

遍历DB_TRX_ID执行以下步骤，直到找到当前事务可见的最新数据：

        遍历方法：如果当前DB_TRX_ID这条记录不满足当前事务的可见性，可通过这条记录的DB_ROLL_PTR回滚指针去取出undo log中前一个版本的DB_TRX_ID

step1：比较DB_TRX_ID 小于 up_limit_id

        如果小于，则当前事务能看到DB_TRX_ID 所在的记录；即该记录是可见的最新的记录

        如果大于等于进入step2

step2：判断 DB_TRX_ID 大于等于 low_limit_id

        如果大于等于则代表DB_TRX_ID 所在的记录在Read View生成后才出现的，那对当前事务肯定不可见，继续遍历下一个DB_TRX_ID

        如果小于则进入step3

step3：判断DB_TRX_ID 是否在活跃事务之中

        如果在，则代表当前事务的Read View生成时刻，DB_TRX_ID这个事务还在活跃，还没有Commit，DB_TRX_ID这个事务修改的数据，当前事务也是看不见的；即对当前事务不可见，继续遍历下一个DB_TRX_ID

        如果不在，则说明，DB_TRX_ID这个事务在当前事务的Read View生成之前就已经Commit了，DB_TRX_ID这个事务修改的结果，对于当前事务是可见的

3. MVCC的工作原理

3.1 MVCC查询的工作流程

3.1.1 查询主键索引

生成Read View读视图

通过主键查找记录，根据记录里的DB_TRX_ID与Read View读视图进行可见性判断

配合DB_ROLL_PTR回滚指针和undo log来找到当前事务可见的数据记录

3.1.2 查询二级索引

生成Read View读视图

比较读视图的up_limit_id与MAX_TRX_ID大小

如果MAX_TRX_ID  小于 本次Read View的up_limit_id，则全部可见，过滤记录中的有效记录

否则，无法通过二级索引判断可见性，需要一次遍历每条记录，反查到聚簇索引记录，通过聚簇索引记录来判断可见性

3.2 MVCC与隔离级别

MVCC 只在 Read Commited 和 Repeatable Read 两种隔离级别下工作。

在RC隔离级别下，是每个快照读都会生成并获取最新的Read View；

这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因

在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。

即RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见

4. 参考

https://www.cnblogs.com/AlmostWasteTime/p/11466520.html

https://www.jianshu.com/p/8845ddca3b23

https://www.zhihu.com/question/27674363/answer/38034982

https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html

https://www.cnblogs.com/xibuhaohao/p/11947041.html

https://blog.csdn.net/qiuyepiaoling/article/details/8054346

https://blog.csdn.net/shaochenshuo/article/details/76137652

https://www.cnblogs.com/stevenczp/p/8018986.html

https://www.cnblogs.com/rongdi/p/13378892.html

https://www.jianshu.com/p/336e4995b9b8

http://mysql.taobao.org/monthly/2015/04/01/

https://www.pianshen.com/article/50271826706/#Innodb__2

http://mysql.taobao.org/monthly/2018/11/04/

https://www.jianshu.com/p/8845ddca3b23

https://www.cnblogs.com/micrari/p/8144339.html

更多的干货好文，欢迎关注公众号：小青菜的技术博客