InnoDB事务日志（redo log 和 undo log）

1.InnoDB事务日志（redo log 和 undo log）

为了最大程度避免数据写入时io瓶颈带来的性能问题( 避免频繁使用io )，MySQL采用了这样一种缓存机制：当query修改数据库内数据时，InnoDB先将该数据从磁盘读取到内存中，修改内存中的数据拷贝，并将该修改行为持久化到磁盘上的事务日志（ 日志的更改顺序是先写内存redo log buffer，再定期批量写入磁盘 ），而不是每次都直接将修改过的数据记录到硬盘内，等事务日志持久化完成 之后 ，内存中的脏数据可以慢慢刷回磁盘，称之为Write-Ahead Logging。事务日志采用的是追加写入，顺序io会带来更好的性能优势。

为了避免脏数据刷回磁盘过程中，掉电或系统故障带来的数据丢失问题，InnoDB采用事务日志（redo log）来解决该问题

1.1 redo log

用于在实例故障恢复时，继续那些已经commit但数据尚未完全回写到磁盘的事务

通常会初始化2个或更多的 ib_logfile 存储 redo log，由参数 innodb_log_files_in_group 确定个数，命名从 ib_logfile0 开始，依次写满 ib_logfile 并顺序重用（in a circular fashion）。如果最后1个 ib_logfile 被写满，而第一个ib_logfile 中所有记录的事务对数据的变更已经被持久化到磁盘中，将清空并重用之

1.2 undo

用于在实例故障恢复时，借助undo log将尚未commit的事务，回滚到事务开始前的状态

记录了数据修改的前镜像。存放于ibdata

1.3 mysql 中undo redo log在事务中起的作用

1.3.1 Undo Log 实现事务的原子性( 原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚 )

  Undo Log的原理很简单， 为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方 （这个存储数据备份的地方称为Undo Log）。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。

1.3.2 Redo Log 实现事务持久性( 持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作 )

 和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交前，只要将Redo Log持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。系统可以根据Redo Log的内容