共计 1666 个字符，预计需要花费 5 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 MySQL 中 Double Write Buffer 的分析是怎样的，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
Double Write Buffer 是什么？
这是一个 buffer，存在于内存中，在持久化到磁盘的时候，这一部分数据会写进 innodb 的表空间里，由一段连续的 pages 组成；
Double Write 这个特性，和命名所描述的完全一致：写两遍~
为什么要引入 Double Write Buffer？
引入 Double Write Buffer 是为了解决 partial page write 的问题，关于这个问题的描述，引用杨大师的原文，
InnoDB 的 Page Size 一般是 16KB，其数据校验也是针对这 16KB 来计算的，将数据写入到磁盘是以 Page 为单位进行操作的。
而计算机硬件和操作系统，在极端情况下（比如断电）往往并不能保证这一操作的原子性，
16K 的数据，写入 4K 时，发生了系统断电 /os crash，只有一部分写是成功的，这种情况下就是 partial page write 问题。
追问 1：抛开 page 不完全写入的这个概念，DB 在做 crash recovery 的时候，不是可以从 redo log 来重新做一遍么，为什么还要这个特性呢？
解答：原因有两个，
1. 由于 Page 的不完全写入，实际上这个出问题的 Page 由于没有完全写入，所以这个 page 的 checksum 是无效的，想恢复这个 page 的时候，无法定位是哪个 page 写出了问题；
2.redo-log 的原因，MySQL 的 innodb 在生成 redo-log 的时候，并没有写入具体数据的变更，而是只记录了这个变更所在的 page 信息，具体的格式如下
[Space-id] [Page-id] [Where-in-the-page-to-modify] [Payload]
其中，space-id 记录的是这个信息存储于哪个 redo-log 文件，page-id 记录的就是 page 的 id（…_(:з」∠)_…），其余信息基本如描述所示；
由于 redo-log 的这种记录方式，使得 MySQL 不能依靠 redo-log 去把崩溃前后一段时间的整个事务全部找出来，然后重做；（存都没存数据，怎么恢复嘛╮(╯▽╰)╭）；
Double Write Buffer 工作在哪个阶段 / 时机？
当 innodb 从 buffer pool 中刷新 pages 到磁盘时，并不是直接往磁盘写，而是先写进这个 Double Write Buffer，
然后马上调用 fsync()，将这一部分数据写到磁盘上，之后再把这部分的 pages 写到真正的数据文件里面去；
Double Write Buffer 能不能解决问题？
答案肯定是可以~
情景 1：innodb 从 buffer pool 往 Double Write Buffer 写 pages 的时候，出事故了，发生了 page 的部分写入；
分析：innodb 在 crash recovery 的时候，检查到数据文件的 pages 都是正常的，通过比较 LSN/checksum 能够检查到数据文件的具体状态，然后再去恢复数据；
情景 2：从 Double Write Buffer 往真正的数据文件写 pages 的时候，出事故了，发生了 page 的部分写入；
分析：由于 Double Write Buffer 本身有这个 pages 的完整内容，从 Double Write Buffer 重新往数据文件写 pages 即可；
Double Write Buffer 对性能的影响？
由于 Double Write Buffer 本身是一段完全连续的空间，所以 Double Write Buffer 从内存写到磁盘的时候是完完全全的顺序写，
所以对性能的影响并没有从 1 个 fsync()到 2 个 fsync()这么夸张，引用 percona 的工程师的判断：性能影响不超过 5%-10%；
关于 MySQL 中 Double Write Buffer 的分析是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
