如下图，分别是insert和delete大致的记录方式。
下面LSN(Log Sequence Number)代表checkpoint，当数据库在LSN为10000时发生宕机，恢复操作仅恢复LSN10000-LSN13000范围内日志
undo是逻辑日志，只是将数据库逻辑地恢复到原来的样子；所有修改都被逻辑地取消了，但是数据结构和页本身在回滚之后可能不大相同。
undo log有两个作用：提供回滚和多个行版本控制(MVCC)。
InnoDB存储引擎回滚时，对于每个INSERT，会完成一个DELETE；对于每个DELETE，会执行一个INSERT；对于每个UPDATE，会执行一个相反的UPDATE，将修改前的行放回去。
MVCC： 当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。
undo log的存储方式innodb存储引擎对undo的管理采用段的方式。rollback segment称为回滚段，每个回滚段中有1024个undo log segment。
在以前老版本，只支持1个rollback segment，这样就只能记录1024个undo log segment。后来MySQL5.5可以支持128个rollback segment，即支持128*1024个undo操作，还可以通过变量 innodb_undo_logs (5.6版本以前该变量是 innodb_rollback_segments )自定义多少个rollback segment，默认值为128。
undo log默认存放在共享表空间中。
当事务提交时，InnoDB存储引擎会做以下两件事：
将undo log放入一个列表中，以供之后的purge使用，是否可以最终删除undo log及所在页由purge线程来判断
判断undo log 所在的页是否可以重用，若可以，分配给下个事务使用
当事务提交时，首先将undo log放入链表中，然后判断undo页的使用空间是否小于3/4，若是，则表示该undo页可以被重用，之后新的undo log记录在当前undo log的后面
undo log分为：
insert undo log
update undo log
因为事务隔离性，insert undo log对其他事务不可见，所以该undo log可以在事务提交后直接删除，不需要进行purge操作。
update undo log记录的是对delete和update操作产生的undo log。该undo log可能需要提供MVCC机制，因此不能提交时就进行删除
update分为两种情况：
update的列如果不是主键列，在undo log中直接反向记录是如何update的。即update是直接进行的。
update主键的操作可以分为两步：
首先将原主键记录标记为已删除，因此需要产生一个类型为TRX_UNDO_DEL_MARK_REC的undo log
之后插入一条新的记录，产生一个类型为TRX_UNDO_INSERT_MARK_REC的undo log
InnoDB purge时，会先从history列表找undo log，然后再从undo page中找undo log；可以避免大量随机读取操作，从而提高purge效率。
MVCC其实就是在每一行记录后面增加两个隐藏列，记录创建版本号和删除版本号，而每一个事务在启动的时候，都有一个唯一的递增的版本号。
MVCC只在REPEATABLE READ 和READ COMMITTED两个隔离级别下工作。读未提交不存在版本问题，序列化则对所有读取行加锁。
示例：
插入操作：记录的创建版本号就是事务版本号
如插入一条记录，事务id假设是1，则创建版本号也是1
id name create version delete version1 test 1
更新操作：先标记旧版本号为已删除，版本号就是当前版本号，再插入一条新的记录
如事务2把name字段更新
update table set name = 'new test' where id = 1;