共計 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 的分析是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。