Mysql Redo Log日志：数据日志与数据落盘机制
Redo log写入磁盘时，必须进行一次操作系统fsync操作，防止redo log只是写入操作系统磁盘缓存中。参数innodb_flush_log_at_trx_commit可以控制redo log日志刷新到磁盘策略。
Mysql Undo Log日志：数据日志与数据落盘机制
数据库崩溃重启后，需要先从redo log中把未落盘的脏页数据恢复回来，重新写入磁盘，保证用户的数据不丢失。当然，在崩溃恢复中还需要把未提交的事务进行回滚操作。由于回滚操作需要undo log日志支持，undo log日志的完整性和可靠性需要redo log日志来保证，所以数据库崩溃需要先做redo log数据恢复，然后做undo log回滚。
在事务执行过程中，除了记录redo一些记录，还会记录undo log日志。Undo log记录了数据每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。
表数据和回滚日志逻辑存储结构图：
Undo log的存储不同于redo log，它存放在数据库内部的一个特殊的段（segment）中，这个段称为回滚段。回滚段位于共享表空间中。Undo段是以undo page为更小组织单位（Segment->Extent->Page）。
Undo page跟储存的数据和索引的页等类似。因为redo log是物理日志，记录的是数据库页的物理修改操作。所以undo log（可以看成数据库的数据）的写入也会伴随着redo log的产生，这是因为undo log也需要持久化的保护。如上图所示：表空间中有回滚段、叶子节点段和非叶子节点段，三者都有对应的页结构。
数据库事务流程：
事务进行过程中，每次sql语句执行，都会记录undo log和redo log，然后更新数据形成脏页，然后redo log会根据时间和空间进行落盘，undo log和脏页会按照checkpointer机制落盘，落盘后相应的redo log就可以删除了。此时，事务还未COMMIT，如果发生崩溃，则首先检查checkpointer记录，使用相应的redo log进行数据恢复和undo log事务回滚。事务执行COMMIT操作时，会将本事务相关的所有redo log进行落盘，只有所有的redo log落盘成功，才算COMMIT成功。然后内存中的undo log和脏页会继续按照checkpointer进行落盘。如果此时发生崩溃，则只使用redo log恢复数据。
