InnoDB内redo log采用的是buffer write，也会遇到这种问题，而且mysql的整体性能对redo log写IO的性能比较敏感，为此InnoDB对该问题做了优化，结合redo log写入是append write的特性，引入了write ahead方法，尝试解决这个问题。主要原理是当某次写文件系统IO满足这两个条件：

a. 该IO的目的地址是文件内的某个page的起始偏移地址；

b. 改IO的数据大小为page大小的整数倍

则该IO的执行，不需要先从磁盘中读出对应page的数据，再做修改和和写入，而是直接将该IO所带的数据作为修改后的数据，缓存在内存里(即page cache)，等后续刷盘操作将该page cache写入到磁盘上。这样就避免了额外的读IO开销。

write ahead的原理比较简单，但是InnoDB内的实现比较精炼，不易理解，容易淡忘。所以，本文以MySQL 8.0.12版本代码为参考，注释分析redo log的write ahead的工作机制，以备后续查记；并简单验证该write ahead机制是否有效。

在MySQL 8.0，innodb将redo log的相关操作，按照功能划分成不同的阶段，由不同的线程负责不同阶段的逻辑。在mini transaction的commit阶段，将该mini transaction产生的redo log拷贝到log_sys->buf内，这部分逻逻辑比较分散，可以发生在用户线程内; log_writer线程，负责将全局的log_sys->buf内的redo log写入文件系统，暂时保存在page cache中；log_flusher线程，负责刷盘，将还处在文件系统的redo log写到磁盘上；log_write_notifier和log_flush_notifier线程，负责触发事件，分别提醒log_writer线程和log_flusher线程从等待中开始工作。

redo log的write ahead逻辑发生在log_writer线程内。该线程逻辑的代码入口在log0write.cc:log_writer函数处；它的工作流程比较简单：

  1. 循环等待条件：log_sys->m_recent_written->m_tail 大于 log_sys->m_written_lsn，条件满足时，说明有新的redo log产生，需要被写入；

下面结合代码分析log_files_write_buffer函数的实现：

总的来说，某次写redo log的IO可能会有以下这四种情况：

a. 该IO的目标偏移量刚好是log_sys->write_ahead_buf当前可以覆盖区域的结尾处，并且该IO要写入的log数据量小于srv_log_write_ahead_size, 则利用log_sys->write_ahead_buf，执行write ahead逻辑：将要写入的log数据拷贝到log_sys->write_ahead_buf内，对log_sys->write_ahead_buf后端未被有效数据填充的区域填0，然后将整个log_sys->write_ahead_buf写入到文件系统中；

b. 该IO的目标偏移量刚好是log_sys->write_ahead_buf当前可以覆盖区域的结尾处，并且该IO要写入的log数据大于srv_log_write_ahead_size, 则不需要执行write ahead操作。将本次写入IO的数据量截断为srv_log_write_ahead_size大小，直接从log_sys->buf将这srv_log_write_ahead_size大小的数据写入到文件系统中，这样既起到了write ahead操作的作用，也避免了write ahead操作所产生的额外内存拷贝的开销。

c. 该IO的目标偏移量不在log_sys->write_ahead_buf当前可以覆盖区域的结尾处，并且该IO要写入的数据小于一个log block的大小，则不需要执行write ahead 操作，但是需要利用log_sys->write_ahead_buf对这个不完整的log block的后端未填入有效log数据的区域填0，并计算checksum等信息，然后将整个log block从log_sys->write_ahead_buf处写入到文件系统中，这个过程会有一次额外的内存拷贝，从log_sys->buf将要写入的log数据拷贝到log_sys->write_ahead_buf内。

d. 该IO的目标偏移量不在log_sys->write_ahead_buf当前可以覆盖区域的结尾处，并且该IO要写入的数据大于一个log block的大小，则也不需要执行write ahead操作。将本次写入IO的数据大小按下截断到OS_FILE_LOG_BLOCK_SIZE的整数倍，然后从log_sys->buf直接写入到文件系统，这样可以较大概率的避免对最后一个不完整log block的填0操作所引入的开销。

下图可以简要的是示意上面介绍的InnoDB内redo log写IO的情况：

a. 该buffer主要有两个作用：a. 用于redo log的write ahead，先将要写入的redo log从log_sys->buf拷贝到log_sys->write_ahead_buf， 再对log_sys->write_ahead_buf后端未被有效数据填充的区域填0；b. 用于对不完整block的后端区域填0。因为原地填0等操作，可能会覆盖后续填入的有效log数据。

b. 参数innodb_log_write_ahead_size

​ 用于控制log_sys->write_ahead_buf的大小，默认为8092；一般需要设置为内存页大小的整数倍，linux下内存页的大小可通过‘getconf PAGE_SIZE’命令获取，内存页的大小一般为4096字节。

附录里有测试的代码，大致的思路是在清空page cache的情况下，按照append write的方式，单线程同步的对一个文件写入1G数据，按两种方式进行对比：a. 普通写入方式，每次写入的数据为512B，直至写完1GB；b. 采用write ahead的方式进行写入，当写入的地址为一个page的起始地址时，则写入一个后端填0的完整page，否则写入512B数据，也是直至写完1GB数据。

对比测试是在同一个物理机的同一块磁盘上进行的(这里就不给出软硬件型号参数了)，磁盘采用的是nvme盘；测试前清空缓存。

分别执行如下命令，进行对比

跑3次取平均值，结果为：

结论: 在page cache不命中的情况下，采用write ahead的方式进行写入的优化效果还是很明显的。