记得刚开始看InnoDB文档的时候，Double Write一节（其实只有一小段）就让我很困惑。无奈当时内力太浅，纠缠了很久也没弄明白。时隔几个月，重新来整理一下。
涉及到的概念：Buffer Pool简称BP，Dirty Page，Log file，Flush，innodb tablespace。
1. 什么是Double Write
在InnoDB将BP中的Dirty Page刷（flush）到磁盘上时，首先会将Page刷到InnoDB tablespace的一个区域中，我们称该区域为Double write Buffer。在向Double write Buffer写入成功后，再择机将数据拷贝到正在的数据文件对应的位置。
咋一看，这个过程有些多余
2. 为什么需要Double Write
InnoDB中有记录（Row）被更新时，先将其在Buffer Pool（简称BP）中的page更新，并将这次更新记录到Log file中，这时候BP中的该page就是被标记为Dirty。在适当的时候（BP不够、系统闲置等），这些Dirty Page会被flush到磁盘上。
试想，在某个Dirty Page（一般是16K）flush的过程中，发生了系统断电（或者OS崩溃），16K的数据只有8K被写到磁盘上，这种现象被称为（partial page writes、torn pages、fractured writes）。一旦partial page writes发生，那么在InnoDB恢复时就很尴尬：在InnoDB的Log file中虽然知道这个数据页被修改了，但是却无法知道这个页被修改到什么程度，和这个页面相关的redo也就无法应用了。
举个例子：在InnoDB的log file中有如下Log：
Log sequence number 0 4285149977
Log sequence number 0 4287355447
Log sequence number 0 4289260680
Log sequence number 0 4291279900
Log sequence number 0 4293359020
其中第1、3个Log修改了该page，但是在断电时，BP中该page只被flush了一部分。那么InnoDB是无法决定上面的Log是否应该被应用的。这时，数据就出现了不一致。
所以，Log file的有效应用，前提是InnoDB的数据文件中的Page是一致的。
简而言之，Double write就是为了避免Partial page writes而设计的。
3. Double Write对性能的影响
系统需要将数据写两份，一般认为，Double Write是会降低系统性能的。peter猜测可能会有5-10%的性能损失，但是因为实现了数据的一致，是值得的。Mark Callaghan认为这应该是存储层面应该解决的问题，放在数据库层面无疑是牺牲了很多性能的。
事实上，Double Write对性能影响并没有你想象（写两遍性能应该降低了50%吧？）的那么大。在BP中一次性往往会有很多的Dirty Page同时被flush，Double Write则把这些写操作，由随机写转化为了顺序写。而在Double Write的第二个阶段，因为Double Write Buffer中积累了很多Dirty Page，所以向真正的数据文件中写数据的时候，可能有很多写操作可以合并，这样有可能会降低Fsync的调用次数。
基于上面的原因，Double Write并没有想象的那么糟。另外，Dimitri在测试后，发现打开和关闭Double Write对效率的影响并不大。
4. 相关参数与状态
是否打开了double write:
root@(none) 07:16:16>show variables like "%double%"; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | innodb_doublewrite | ON | +--------------------+-------+
Double write的使用情况：
root@(none) 07:15:50>SHOW STATUS LIKE "%innodb_dblwr%"; +----------------------------+-----------+ | Variable_name | Value | +----------------------------+-----------+ | Innodb_dblwr_pages_written | 145373349 | | Innodb_dblwr_writes | 2249336 | +----------------------------+-----------+
上面可以看到，从BP共Flush了145373349个Pages到double write buffer中；一共调用了2249336次write写到真正的数据文件。可见，相当于每次write合并了 145373349 / 2249336 = 64.6次Flush。（这就是为什么double write buffer为什么并不会对效率有很大影响的原因）
5. 我的看法
在某些文件系统（ZFS等）层面能够保证不出现Partial page writes时，可以关闭Double Write。因为它对性能影响并不大，一般情况都建议打开，毕竟带来的数据安全性保障可能是我们更关心的。
参考文献：
[0]. Manual about Double Write
[1]. Innodb Double Write
[2]. Do you need the InnoDB doublewrite buffer
[3]. MySQL Performance: InnoDB Doublewrite Buffer Impact
博主是高人啊，拜读了，呵呵
高手，研究的很透！
文章写的不错~~不知道倪是使用的JustHost主机吗?
回复JustHost：不是的，是在一个江西的空间商的
一直想不通，mysql在做checkpoint时，记录什么信息，楼主的例子，但数据不一致时，mysql能否从一个较早的checkpoint的点开始应用redo log，这样能否解决数据一致性的问题。另外，这个有点取决于redo log内部的结构体，即redo log的record记录的是什么?
感觉如果redo log记录的是基于sql的，那么数据不一致时重做redo log就会有问题，而如果redo log记录是基于block的，那么数据不一致时重做redo log就会有问题。不知楼主如何解答，盼能恢复一下
以上是两个问题：
不管是否innodb_flush_method=O_DIRECT，LOG的FLUSH都是以FSYNC方式进行，所以FLUSH的时候对内存要求没那么多。
（这一点我觉得如果你只调整LOG大小，肯定没用）
另外，innodb_flush_method=O_DIRECT 以后，减少了对内存的使用，导致减少了对SWAP的使用，IO肯定下来的；
不管是否innodb_flush_method=O_DIRECT，从磁盘读的IO数据肯定是等量的，关键是系统在处理读数据的时候，采用OS CACHE 需要使用到SWAP了，出现换入换出。这里可能产生不少IO；
建议楼主只调一个参数，这样追踪问题比较快速；
回复felix：
我个人觉得作者在这个概念上说得不是很清楚。如果没有doublewrite buffer，在直接写物理磁盘的时候，如果发生了系统崩溃，那么如果页没有损坏（这个损坏我一直没找到很好的词语来说得更形象）那么通过redo log是能恢复的，因为redo本身就是记录的页物理上的改变，而如果发生了页损坏呢？那么如果没有doublewrite buffer这个功能是不是就无法进行恢复了？或者能恢复但是一定会造成数据丢失呢？ 所以doublewrite buffer主要的功能就是防止页损坏。
不知这样理解对么？