redo日志和undo日志

REDO LOG

称为重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。
事务提交后，刚写完缓冲池，数据库宕机了，那么这段数据就是丢失的，无法恢复。对于一个已经提交的事务，在事务提交后即使系统发生了崩溃，这个事务对数据库中所做的更改也不能丢失。那么我们就需要让已经提交了的事务对数据库中数据所做的修改永久生效，即使后来系统崩溃，在重启后也能把这种修改恢复出来。这时引入redo日志，把修改了的部分记录在文件中，需要恢复时直接拿来用。

优点：

• redo日志降低了刷盘频率
• redo日志占用的空间非常小

特点：

• redo日志是顺序写入磁盘的
• 事务执行过程中，redo log不断记录

redo log 和 bin log
redo log是存储引擎层的，bin log是数据库层。bin log用于主从复制，保持数据的一致性，主机写入一条记录，并写入bin log日志，从机再从bin log日志中复制过来。在对表进行插入的过程中，redo log不断进行顺序记录，而bin log不会记录，直到这个事务提交，才一次性写入bin log文件中。

redo的整体流程

innodb的更新操作是采用write ahead log（预先日志持久化）策略，即先写日志再写入磁盘。

InnoDB给出innodb_flush_log_at_trx_commit 参数，该参数控制 commit提交事务时，如何将 redo log buffer 中的日志刷新到 redo log file 中。它支持三种策略：
设置为0 ：表示每次事务提交时不进行刷盘操作。（系统默认master thread每隔1s进行一次重做日志的同步）
设置为1 ：表示每次事务提交时都将进行同步，刷盘操作（ 默认值，最可靠但效率低）
设置为2 ：表示每次事务提交时都只把 redo log buffer 内容写入 page cache，不进行同步。由os自己决定什么时候同步到磁盘文件。

UNDO LOG

称为回滚日志，回滚行记录到某个特定版本，用来保证事务的原子性、一致性。
在事务中，对一条记录做改动（插入、删除、修改）之前，写入undo 日志，注意查询操作不计入undo日志。
此外，undo log会产生redo log，因为undo log也需要持久性的保护。

undo日志的作用：
1.回滚数据。undo 日志仅将数据逻辑的恢复到之前的状态，而不是物理层面。数据结构和页本身可能与原先大不相同。
2.mvcc并发控制。

小结

undo log是逻辑日志，对事务回滚时，只是将数据库逻辑地恢复到原来的样子。
redo log是物理日志，记录的是数据页的物理变化，undo log不是redo log的逆过程。