在极端情况下（比如断电）往往并不能保证这一操作的原子性，16K的数据，写入4K 时，发生了系统断电/os crash ，只有一部分写是成功的，这种情况下就是 partial page write 问题。有人会想到系统恢复后MySQL可以根据redolog 进行恢复，而mysql在恢复的过程中是检查page的checksum，checksum就是pgae的最后事务号，发生partial page write 问题时，page已经损坏，找不到该page中的事务号，就无法恢复。
表面看上去，它是每个页面都写了2遍，会非常影响性能。但实际上，由于所写的页面会先缓存到内存中，因此每一部分缓存空间在满了之后才会真正地写入文件。并且doublewrite是一个连接的存储空间，所以硬盘在写数据的时候是顺序写，而不是随机写，这样性能很高。doublewrite有效利用这个特地那，所以降低并不会相差1倍，经过测试，大概5-10%左右。当然，这是针对普通磁盘。对于目前比较流行的SSD来说，随机写已经不是问题，性能影响可能更小。
doublewrite默认开启，参数skip_innodb_doublewrite虽然可以禁止使用doublewrite功能，但还是强烈建议大家使用doublewrite。避免部分写失效问题，当然，如果你的数据表空间放在本身就提供了部分写失效防范机制的文件系统上，如ZFS/FusionIO/DirectFS文件系统，在这种情况下，就可以不开启doublewrite了。
其实两次写并不是什么特性或优点，它只是一个被动解决方案而已。这个问题的本质就是磁盘在写入时，都是以512字节为单位，不能保证MySQL数据页面16KB的一次性原子写，所以才有可能产生页面断裂的问题。而目前有些厂商从硬件驱动层面做了优化，可以保证16KB（或其他配置）数据的原子性写入。如果真是这样，那么两次写就完全没有必要了，取消两次写，才是最终级优化，值得期待。
两次写的作用
在数据库启动时（异常关闭的情况下），都会做数据库恢复（redo）操作，恢复的过程中，数据库都会检查页面是不是合法（校验等等），如果发现一个页面校验结果不一致，则此时会用到两次写这个功能，这个特点也正是为了处理这样的错误而设计的。
此时的操作很明白了，将两次写的2个BLOCK（簇）都读出来，然后将所有这些页面写回到对应的页面中去，那么这时可以保证这些页面是正确的，并且是在写入前已经更新过的（最新数据）。在写回对应页面中去之后，那么就可以在这基础上继续做数据库恢复了，之后则不会再遇到这样的问题了，因为已经将最后有可能产生写断裂的数据页面都恢复了。
如果是写doublewrite buffer本身失败，那么这些数据不会被写到磁盘，InnoDB此时会从磁盘载入原始的数据，然后通过InnoDB的事务日志来计算出正确的数据，重新写入到doublewrite buffer。
