基于上述判断，如果记录不可见，则尝试使用undo去构建老的版本(row_vers_build_for_consistent_read)，直到找到可以被看见的记录或者解析完所有的undo。
针对RR隔离级别，在第一次创建readview后，这个readview就会一直持续到事务结束，也就是说在事务执行过程中，数据的可见性不会变，所以在事务内部不会出现不一致的情况。针对RC隔离级别，事务中的每个查询语句都单独构建一个readview，所以如果两个查询之间有事务提交了，两个查询读出来的结果就不一样。从这里可以看出，在InnoDB中，RR隔离级别的效率是比RC隔离级别的高。此外，针对RU隔离级别，由于不会去检查可见性，所以在一条SQL中也会读到不一致的数据。针对串行化隔离级别，InnoDB是通过锁机制来实现的，而不是通过多版本控制的机制，所以性能很差。
由于readview的创建涉及到拷贝全局活跃读写事务id，所以需要加上trx_sys->mutex这把大锁，为了减少其对性能的影响，关于readview有很多优化。例如，如果前后两个查询之间，没有产生新的读写事务，那么前一个查询创建的readview是可以被后一个查询复用的。
垃圾回收Purge线程Purge线程主要做两件事，第一，数据页内标记的删除操作需要从物理上删除，为了提高删除效率和空间利用率，由后台Purge线程解析undolog定期批量清理。第二，当数据页上标记的删除记录已经被物理删除，同时undo所对应的记录已经能被所有事务看到，这个时候undo就没有存在的必要了，因此Purge线程还会把这些undo给truncate掉，释放更多的空间。
Purge线程有两种，一种是Purge Worker(srv_worker_thread), 另外一种是Purge Coordinator(srv_purge_coordinator_thread)，前者的主要工作就是从队列中取出Purge任务，然后清理已经被标记的记录。后者的工作除了清理删除记录外，还需要把Purge任务放入队列，唤醒Purge Worker线程，此外，它还要truncate undolog。
我们先来分析一下Purge Coordinator的流程。启动线程后，会进入一个大的循环，循环的终止条件是数据库关闭。在循环内部，首先是自适应的sleep，然后才会进入核心Purge逻辑。sleep时间与全局历史链表有关系，如果历史链表没有增长，且总数小于5000，则进入sleep，等待事务提交的时候被唤醒(srv_purge_coordinator_suspend)。退出循环后，也就是数据库进入关闭的流程，这个时候就需要依据参数innodb_fast_shutdown来确定在关闭前是否需要把所有记录给清除。接下来，介绍一下核心Purge逻辑。
首先依据当前的系统负载来确定需要使用的Purge线程数(srv_do_purge)，即如果压力小，只用一个Purge Cooridinator线程就可以了。如果压力大，就多唤醒几个线程一起做清理记录的操作。如果全局历史链表在增加，或者全局历史链表已经超过innodb_max_purge_lag，则认为压力大，需要增加处理的线程数。如果数据库处于不活跃状态(srv_check_activity)，则减少处理的线程数。
如果历史链表很长，超过innodb_max_purge_lag，则需要重新计算delay时间(不超过innodb_max_purge_lag_delay)。如果计算结果大于0，则在后续的DML中需要先sleep，保证不会太快产生undo(row_mysql_delay_if_needed)。
从全局视图链表中，克隆最老的readview，所有在这个readview开启之前提交的事务所产生的undo都被认为是可以清理的。克隆之后，还需要把最老视图的创建者的id加入到view->descriptors中，因为这个事务修改产生的undo，暂时还不能删除(read_view_purge_open)。
从undo segment的最小堆中，找出最早提交事务的undolog(trx_purge_get_rseg_with_min_trx_id)，如果undolog标记过delete_mark(表示有记录删除操作)，则把先关undopage信息暂存在purge_sys_t中(trx_purge_read_undo_rec)。
依据purge_sys_t中的信息，读取出相应的undo，同时把相关信息加入到任务队列中。同时更新扫描过的指针，方便后续truncate undolog。
循环第4步和第5步，直到全局历史链表为空，或者接下到view->low_limit_no，即最老视图创建时已经提交的事务，或者已经解析的page数量超过innodb_purge_batch_size。
把所有的任务都放入队列后，就可以通知所有Purge Worker线程(如果有的话)去执行记录删除操作了。删除记录的核心逻辑在函数row_purge_record_func中。有两种情况，一种是数据记录被删除了，那么需要删除所有的聚集索引和二级索引(row_purge_del_mark)，另外一种是二级索引被更新了(总是先删除+插入新记录)，所以需要去执行清理操作。
在所有提交的任务都已经被执行完后，就可以调用函数trx_purge_truncate去删除update undo(insert undo在事务提交后就被清理了)。每个undo segment分别清理，从自己的histrory list中取出最早的一个undo，进行truncate(trx_purge_truncate_rseg_history)。truncate中，最终会调用fseg_free_page来清理磁盘上的空间。
事务的复活