一、undo日志介绍
上一节详细的说了redo日志，redo日志的功能就是把增删改操作都记录着，如果断电导致内存中的脏页丢失，可以根据磁盘中的redo日志文件进行恢复。redo日志被设计出来是为了保证数据库的持久性，undo日志设计出来是为了保证数据库的原子性。一个事务开启之后，做增删改操作，会记录redo日志，但是如果后悔了进行回滚，redo日志是做不到回退的，这时候就需要undo日志了。
总结：记住一句话，redo日志保证了数据库的持久性，undo日志保证了数据库的原子性。
二、undo日志格式
一般每次对记录做一次改动就会对应生成一条undo日志。有些更新语句记录的操作中，也可能会生成两条undo日志。
一个事务在执行过程中可能新增，删除，更新若干条记录，同样也会生成若干条记录，这些undo日志会从0开始编号，并且是按照顺序生成，被称为第0号undo日志，1号。。。
这些undo日志是被记录到类型为FIL_PAGE_UNDO_LOG页面。这些页面可以从系统表空间（ibdata1文件）中分配，也可以从一种专门存放undo日志的表空间，也就是undo tablespace。
insert操作对应的undo日志
前面文章说过，插入操作分为乐观插入和悲观插入。但是关于插入操作无非就是把记录放到数据页中，如果想要回滚就直接把这条记录删除就可以，也就是说在写对应的undo日志时，主要是把这条记录的主键记录，这样删除记录就可以根据主键找到二级索引和聚簇索引上的记录。InnoDB设计了一个类型为为TRX_UNDO_INSERT_REC的undo⽇志
属性说明：
undo no上面说过，从0开始，只要这个事务没提交，按顺序生成undo日志，依次递增。
主键的每个列占用的存储空间和真实值。为什么存储主键就可以了，上面也说了，如果想要回滚就直接把这条记录删除就可以，也就是说在写对应的undo日志时，主要是把这条记录的主键记录，这样删除记录就可以根据主键找到二级索引和聚簇索引上的记录。后面的delete和update也一样不再强调。
因为主键只包含id，所以插入的两条记录，会按照顺序生成两个undo日志，第一个undo日志：
第二个undo日志：
roll_pointer隐藏列的含义
前面的文章介绍过记录的三个隐藏列，只剩roll_pointer没有说过，他本质上就是一个指向记录对应的undo日志的一个指针，比方说上面的插入两条记录的操作，每条记录都有对应的一个undo日志。关系就是记录被存储到类型为FIL_PAGE_INDEX的页面（前面说的数据页），undo日志被放到类型为FIL_PAGE_UNDO_LOG的页面中
delete操作对应的undo日志
前面的文章详细的说过数据页中的记录会组成一个单向链表，我们把这个链表称之为正常记录链表。并且删除某条记录，被删除的记录也会形成一个链表，叫垃圾链表，并且这条垃圾链表中记录占用的存储空间可以被重新利用。
上图简化了记录，只标记了delete_mask属性，我们删除最后一条记录，删除的过程需要经历两个阶段：
阶段一：只是将该记录的delete_mask表示为设置为1，修改记录隐藏列trx_id、roll_pointer这些隐藏列的值。
在事务提交之前，删除的记录都处于这个中间状态，被删除的记录没有被加入垃圾链表（为了实现MVCC功能）。
阶段二：当删除的语句所在事务提交之后，会有专门的线程把记录加入垃圾链表中，并且调整页面的其他信息。这个阶段称为purge。
把阶段二执行完了，这条记录就算真正的删除了，这条已删除的记录占用的存储空间也可以被重新利用了。
从上图我们可以看到真正删除之后被删除的记录加入垃圾链表的头结点，修改垃圾链表PAGE_FREE属性的值。
undo日志使用的ibp，到底有没有undo buffer？
undo日志写在磁盘的系统表空间，即数据目录的ibdata1文件中，是字扩展文件
undo日志刷入磁盘的时机，比redo日志还之前。
undo页其实在事务提交之后就没用了，就可以删除了。
参考：
003_Mysql之事务详解redo log、undolog 和 MVCC_undolog存放在磁盘的哪里-CSDN博客
