InnoDB’s 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。
what？
DML操作导致的数据记录变化，均需要将记录的前镜像写入Undo日志；
逻辑日志；
when?
DML操作修改聚簇索引前，记录Undo日志(Undo日志，先于Redo日志)
二级索引记录的修改，不记录Undo日志；
注意：Undo页面的修改，同样需要记录Redo日志；
Insert/Delete/Update分别会如何记录日志？
InnoDB内存中，DML操作顺序如下：
–写Undo(获取ROLLBACK_PTR系统列)
–修改Page
–写Redo的顺序
Insert:
将插入记录的主键值，写入Undo；
Delete:
1. Delete，在InnoDB内部为Delete Mark操作，将记录上标识Delete_Bit，而不删除记录；
2. 将当前记录的系统列写入Undo (DB_TRX_ID, ROLLBACK_PTR, ...)；
3. 将当前记录的主键列写入Undo；
4. 将当前记录的所有索引列写入Undo；
5. 将Undo Page的修改，写入Redo；
Update(未修改聚簇索引键值)
1. 将当前记录的系统列写入Undo (DB_TRX_ID, ROLLBACK_PTR, ...)；
2. 将当前记录的主键列写入Undo；
3. 将当前Update列的前镜像写入Undo；
4. 若Update列中包含二级索引列，则将二级索引其他未修改列写入Undo；
5. 将Undo页面的修改，写入Redo；
Update(修改聚簇索引键值)
1. 不可进行In Place Update。Update = Delete Mark + Insert；
2. 对原有记录进行Delete Mark操作，写入Delete Mark操作Undo；
3. 将新纪录插入聚簇索引，写入Insert操作Undo；
4. 将Undo页面的修改，写入Redo；
undo的功能：
1. 实现事务的原子性，即当事务由于意外情况未能运行时，可以使得事务回滚，从而使得数据恢复到事务开始运行时的状态；
2. 实现一致性非锁定读。如果读取的行正在执行delete或者update操作，这时读取操作不会因此去等待行上锁的释放。相反，InnoDB存储引擎会去读取行的一个快照数据；
3. 用户的DML操作，均要记录undo；
undo页重用：
InnoDB存储引擎允许在一个页中存放多个不同事务的undo日志。若在OLTP应用环境中，事务通常都比较小，因此产生的undo日志相对较小。而由于其他事务可能正在引用当前的记录，事务在提交时并不能直接将undo日志给删除。
在InnoDB存储引擎的设计中对undo页可以进行重用，即一个undo页中允许存放多个不同事务的undo日志。具体来说，当事务提交时，首先将undo log放入到链表中，然后判断当前undo页的使用空间是否小于3/4。如果小于，表示该undo页可以被重用，之后新产生的undo记录保存在当前undo log的后面。由于存放undo log的history链表是以undo记录进行链接的，而undo页可能存放着不同事务的undo日志，因此purge操作需要涉及磁盘的离散读取操作，是一个比较缓慢的过程。
purge清理操作：
purge操作主要进行2个清理操作：
1. 清理记录。删除已经标记为delete mark的记录或者其他相关辅助索引记录；
2. 清理undo日志。若undo页中的所有undo记录都被删除，则删除对应的undo段。
在清理undo日志时，需要判断当前是否有其他事务在通过undo日志进行多版本并发控制，若有，则不能立即进行undo日志的清理，仅当没有任何一个用户事务使用该undo日志时，才可以进行清理。
为何需要按照操作类型，分为insert_undo与update_undo？
目标：为了实现Undo Page的分类回收；
insert_undo：
所有的Undo Page，在事务提交后，可直接回收释放；
update_undo：
所有的Undo Page，事务提交后，不可立即回收释放；
需要遍历其中的Undo日志，删除索引中的过期版本记录(Purge)；然后才可释放；
mysql 5.1中undo的purge是和master thread 共用一个线程，则可能的purge的速度到达了瓶颈；
mysql 5.5中有独立的purge线程可以很快的回收掉undo log；
mysql 5.6中可以单独设置undo tablespace文件，避免与ibdata1混用在一起；
innodb_undo_tablespaces 回滚表空间个数
innodb_undo_directory 回滚表空间位置
从共享表空间独立出来，从而不至于单个表空间文件过大。