​redo log的被动刷盘机制

在MySQL事务执行的过程中，innodb引擎会产生redo log，我们知道，MySQL的事务提交是两阶段提交的，画图如下：

通常来讲，redo log刷盘的时机是在事务提交的commit阶段采取刷盘的，在此之前，redo log都存在于redo log buffer这块指定的内存区域中。

这里我们首先要明确两个概念和两个参数：

write：刷盘

fsync：持久化到磁盘

write(刷盘)指的是MySQL从buffer pool中将内容写到系统的page cache中，并没有持久化到系统磁盘上。这个速度其实是很快的。

fsync指的是从系统的cache中将数据持久化到系统磁盘上。这个速度可以认为比较慢，而且也是IOPS升高的真正原因。

参数：

innodb_flush_logs_at_trx_commit（该参数针对redo log）

取值0：每次提交事务都只把redo log留在redo log buffer中

取值1：每次提交事务都将redo log 持久化到磁盘上，也就是write+fsync

取值2：每次都把redo log写到系统的page cache中，也就是只write，不fsync

sync_binlog（改参数针对binlog）

取值0：每次提交都将binlog 从binlog cache中 write到磁盘上，而不fsync到磁盘

取值1：每次提交事务都将binlog fsync到磁盘上

取值N：每次提交事务都将binlog write到磁盘上，累计N个事务之后，执行fsync

但是，在某些特定场景下，redo log会在commit这个动作到来之前进行刷盘操作，例如下面的两种情况会让没有提交的事务的redo log写入磁盘：

1、redo log buffer占用的空间即将达到buffer pool的一般的时候，后台线程会主动刷盘，这个时候，由于事务没有提交，所以仅仅是将redo log buffer中的内容通过write的方法写入到系统的cache中，没有进行fsync的持久化动作。

2、并行提交事务的时候，会顺带将上一个事务的部分redo log从redo log buffer中fsync到磁盘上，例如下面的例子：

假设redo log buffer中的内容如下（假设每个事务的redo log有4部分）：

redo log B1

redo log A1

redo log B2

redo log B3

redo log B4

此时，事务B发生了commit操作，而设置的innodb_flush_logs_at_trx_commit的值是1，那么会触发事务B的redo log持久化到磁盘。此时事务A的一部分redo log，也就是redo log A1会被顺带着持久化fsync到磁盘中。

这里还需要说明一点，因为MySQL的innodb存储引擎时需要支持崩溃恢复的，依赖prepare阶段的redo log ，所以，如果innodb_flush_logs_at_trx_commit的值是1，MySQL会在redo log的prepare阶段就进行一次持久化redo log的fsync操作。这个fsync的存在，再加上每秒一次的后台刷盘操作，innodb会认为redo log在commit的时候，就不需要fsync了，只write到文件系统的page cache就够了。

所以，真正的两阶段提交，应该是下面这个样子：

之所以redo log的write和fsync没有连接在一起，其实是考虑到了组提交的功能，分开来进行这两个步骤，在并发的场景下，可以让这一组一次性提交的redo log更多一点，从而一次性fsync更多的组员。

最后，回答一个问题，我们知道innodb采用了WAL技术(先写log，再写磁盘)来减少磁盘写。但是我们上面的分析过程不难看出，在事务提交的过程中，redo log prepare阶段会进行一次fsync磁盘，binlog 阶段也会fsync一次磁盘，这似乎并没有减少与磁盘的交互，MySQL这样设计的意义是什么？

其实这样的目的有两个：

其一：redo log和binlog都是顺序写，顺序写比数据页的随机写节约时间，性能更高

其二：组提交机制使得我们不用每个事务都进行写磁盘操作，而是将多个写操作放在一个组里面，这样可以大幅度降低磁盘的IOPS