在InnoDB存储引擎中，undo日志有两个作用：
1. 实现事务的原子性，即当事务由于意外情况未能运行时，可以使得事务回滚，从而使得数据恢复到事务开始运行时的状态；
2. 实现一致性非锁定读。如果读取的行正在执行delete或者update操作，这时读取操作不会因此去等待行上锁的释放。相反，InnoDB存储引擎会去读取行的一个快照数据。
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日志时，才可以进行清理。
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 回滚表空间位置
从共享表空间独立出来，从而不至于单个表空间文件过大。