本文是对整个Undo生命周期过程的阐述，代码分析基于当前最新的MySQL5.7版本。本文也可以作为了解整个Undo模块的代码导读。由于涉及到的模块众多，因此部分细节并未深入。
前言Undo log是InnoDB MVCC事务特性的重要组成部分。当我们对记录做了变更操作时就会产生undo记录，Undo记录默认被记录到系统表空间(ibdata)中，但从5.6开始，也可以使用独立的Undo 表空间。
Undo记录中存储的是老版本数据，当一个旧的事务需要读取数据时，为了能读取到老版本的数据，需要顺着undo链找到满足其可见性的记录。当版本链很长时，通常可以认为这是个比较耗时的操作（例如bug#69812）。
大多数对数据的变更操作包括INSERT/DELETE/UPDATE，其中INSERT操作在事务提交前只对当前事务可见，因此产生的Undo日志可以在事务提交后直接删除（谁会对刚插入的数据有可见性需求呢！！），而对于UPDATE/DELETE则需要维护多版本信息，在InnoDB里，UPDATE和DELETE操作产生的Undo日志被归成一类，即update_undo。
基本文件结构为了保证事务并发操作时，在写各自的undo log时不产生冲突，InnoDB采用回滚段的方式来维护undo log的并发写入和持久化。回滚段实际上是一种 Undo 文件组织方式，每个回滚段又有多个undo log slot。具体的文件组织方式如下图所示：
上图展示了基本的Undo回滚段布局结构，其中:
rseg0预留在系统表空间ibdata中;
rseg 1~rseg 32这32个回滚段存放于临时表的系统表空间中;
rseg33~ 则根据配置存放到独立undo表空间中（如果没有打开独立Undo表空间，则存放于ibdata中）
如果我们使用独立Undo tablespace，则总是从第一个Undo space开始轮询分配undo 回滚段。大多数情况下这是OK的，但假设我们将回滚段的个数从33开始依次递增配置到128，就可能导致所有的回滚段都存放在同一个undo space中。(参考函数trx_sys_create_rsegs 以及 bug#74471)
每个回滚段维护了一个段头页，在该page中又划分了1024个slot(TRX_RSEG_N_SLOTS)，每个slot又对应到一个undo log对象，因此理论上InnoDB最多支持 96 * 1024个普通事务。
在MySQL的InnoDB存储引擎中count(*)函数的优化
MySQL Server 层和 InnoDB 引擎层 体系结构图
关键结构体为了便于管理和使用undo记录，在内存中维持了如下关键结构体对象：
所有回滚段都记录在trx_sys->rseg_array，数组大小为128，分别对应不同的回滚段；
rseg_array数组类型为trx_rseg_t，用于维护回滚段相关信息；
每个回滚段对象trx_rseg_t还要管理undo log信息，对应结构体为trx_undo_t，使用多个链表来维护trx_undo_t信息;
事务开启时，会专门给他指定一个回滚段，以后该事务用到的undo log页，就从该回滚段上分配;
事务提交后，需要purge的回滚段会被放到purge队列上(purge_sys->purge_queue)。
各个结构体之间的联系如下：
当开启一个读写事务时（或者从只读事务转换为读写事务），我们需要预先为事务分配一个回滚段：
对于只读事务，如果产生对临时表的写入，则需要为其分配回滚段，使用临时表回滚段（第1~32号回滚段），函数入口：trx_assign_rseg -->trx_assign_rseg_low-->get_next_noredo_rseg。
在MySQL5.7中事务默认以只读事务开启，当随后判定为读写事务时，则转换成读写模式，并为其分配事务ID和回滚段，调用函数：trx_set_rw_mode -->trx_assign_rseg_low --> get_next_redo_rseg。
普通回滚段的分配方式如下：