InnoDB引擎WAL机制之Redo Log

Write-Ahead

一个事务要修改多张表的多条记录，多条记录分布在不同的Page里面，对应到磁盘的不同位置。如果每个事务都直接写磁盘，一次事务提交就要多次磁盘的随机I/O，性能达不到要求。怎么办呢？不写磁盘，在内存中进行事务提交。然后再通过后台线程，异步地把内存中的数据写入到磁盘中。但有个问题：机器宕机，内存中的数据还没来得及刷盘，数据就丢失了。

为此，就有了Write-ahead Log的思路：先在内存中提交事务，然后写日志（所谓的Write-ahead Log），然后后台任务把内存中的数据异步刷到磁盘。日志是顺序地在尾部Append，从而也就避免了一个事务发生多次磁盘随机 I/O 的问题。明明是先在内存中提交事务，后写的日志，为什么叫作Write-Ahead呢？这里的Ahead，其实是指相对于真正的数据刷到磁盘，因为是先写的日志，后把内存数据刷到磁盘，所以叫Write-Ahead Log。

内存操作数据+Write-Ahead Log的这种思想非常普遍，后面讲LSM树的时候，还会再次提到这个思想。在多备份一致性中，复制状态机的模型也是基于此。

具体到InnoDB中，Write-Ahead Log是Redo Log。在InnoDB中，不光事务修改的数据库表数据是异步刷盘的，连Redo Log的写入本身也是异步的。

如图所示，在事务提交之后，Redo Log先写入到内存中的Redo Log Buffer中，然后异步地刷到磁盘上的Redo Log。为此，InnoDB有个关键的参数innodb_flush_log_at_trx_commit控制Redo Log的刷盘策略，该参数有三个取值：

0：每秒刷一次磁盘，把Redo Log Buffer中的数据刷到Redo Log（默认为0）。
1：每提交一个事务，就刷一次磁盘（这个最安全）。
2：不刷盘。然后根据参数innodb_flush_log_at_timeout设置的值决定刷盘频率。

很显然，该参数设置为0或者2都可能丢失数据。设置为1最安全，但性能最差。InnoDB设置此参数，也是为了让应用在数据安全性和性能之间做一个权衡。

总结

• InnoDB的WAL 机制就是redo log
• 为何要WAL?避免随机写入 提高速度,log是顺序写入的