innodb存储引擎中的redo log和undo log

redo log重做日志，用来保证事务的原子性和持久性。
undo log，用来保证事务的一致性，帮助事务的回滚和MVCC的功能。

区别与联系：
redo恢复提交事务修改的页操作，而undo回滚行记录到某个特定版本。
二者记录的内容不同，redo通常是物理日志，记录的是页的物理修改操作。undo是逻辑日志，根据每行记录进行记录。
redo log基本上是顺序写的，在数据库运行时，不需要对redo log的文件进行读取操作，而undo log是需要进行随机读写的。

具体介绍：
1）redo log
重做日志由2个部分组成，一是内存中搞得重做日志缓存（redo log buffer），其是易失的；二是重做日志文件（redo log file），是持久的。为了确保每次日志都写入重做日志文件，在每次将重做日志缓存写入重做日志文件后，InnoDB存储引擎都需要调用一次fsync操作。
重做日志，都是以512字节存储，所以，重做日志缓存、重做日志文件都以块Block保存，成为日志快。若一个页中产生的重做日志数量大于512字节，需要分割为多个重做日志块来存储。此外，由于重做日志块的大小和磁盘扇区大小一样，都为512字节，因此，重做日志的写入可以保证原子性，不需要doubleWrite技术。
2）undo log
在数据库进行修改时，InnoDB存储引擎，不但会产生redo log，还会产生一定量的undo。这样，如果用户执行的事务或语句由于某种原因失败了，又或者用户一条rollback的语句请求回滚，就可以利用undo将数据回滚到修改之前的样子。
undo存放在数据库内部的一个segment中，成为undo段，位于共享表空间中。
undo是逻辑日志，因此，只是将数据库逻辑的恢复到原来的样子，所有修改都逻辑的取消了，但是数据结构和页本身在回滚之后，可以能打不相同。例如，一个事务在修改当前一个页中某几条记录，同时还有别的事务，在同一个页中另外几条记录进行修改。因此，不能将一个页回滚到事务开始的样子，因为这样会影响其他事务正在进行的工作。
InnoDB存储引擎的MVCC是通过undo来完成。当用户读取一条记录时，若记录已被其他事务占用，当前事务可通过undo读取之前的行版本信息，进行锁定读取。
undo log会产生redo log，undo log需要持久化保护。事务提交后，并不能马上删除undo log所在的页。因为还有其他事务通过undo log来得到行记录之前的版本。故事务提交时，将undo log放在一个链表中，是否可以最终删除undo log及undo log所在的页，是由purge线程来判断。
目前删除处理：将主键列等于x的记录的delete_flag设为1，记录没有被删除。

3）purge"清除"线程
purge用于完成delete和update操作。
这样设计是因为InnoDB支持MVCC，所以，记录不能在事务提交时立即进行处理。这时其他事务可能正在利用这行，故InnoDB需要保持记录之前的版本。而是否删除这条记录通过purge来判断。若该行记录已不被任何其他事务引用，可真正delete。