上篇《緩沖池(buffer pool)，徹底懂了!》介紹了InnoDB緩沖池的工作原理。

簡單回顧一下：

• MySQL數據存儲包含內存與磁盤兩個部分;
• 內存緩沖池(buffer pool)以頁為單位，緩存最熱的數據頁(data page)與索引頁(index page);
• InnoDB以變種LRU算法管理緩沖池，并能夠解決“預讀失效”與“緩沖池污染”的問題;

畫外音：細節詳見《緩沖池(buffer pool)，徹底懂了!》。

毫無疑問，對于讀請求，緩沖池能夠減少磁盤IO，提升性能。問題來了，那寫請求呢?

情況一

假如要修改頁號為4的索引頁，而這個頁正好在緩沖池內。

如上圖序號1-2：

• 直接修改緩沖池中的頁，一次內存操作;
• 寫入redo log，一次磁盤順序寫操作;

這樣的效率是***的。

畫外音：像寫日志這種順序寫，每秒幾萬次沒問題。

是否會出現一致性問題呢?

并不會。

• 讀取，會***緩沖池的頁;
• 緩沖池LRU數據淘汰，會將“臟頁”刷回磁盤;
• 數據庫異常奔潰，能夠從redo log中恢復數據;

什么時候緩沖池中的頁，會刷到磁盤上呢?

定期刷磁盤，而不是每次刷磁盤，能夠降低磁盤IO，提升MySQL的性能。

畫外音：批量寫，是常見的優化手段。

情況二

假如要修改頁號為40的索引頁，而這個頁正好不在緩沖池內。

此時麻煩一點，如上圖需要1-3：

• 先把需要為40的索引頁，從磁盤加載到緩沖池，一次磁盤隨機讀操作;
• 修改緩沖池中的頁，一次內存操作;
• 寫入redo log，一次磁盤順序寫操作;

沒有***緩沖池的時候，至少產生一次磁盤IO，對于寫多讀少的業務場景，是否還有優化的空間呢?

這即是InnoDB考慮的問題，又是本文將要討論的寫緩沖(change buffer)。

畫外音：從名字容易看出，寫緩沖是降低磁盤IO，提升數據庫寫性能的一種機制。

什么是InnoDB的寫緩沖?

在MySQL5.5之前，叫插入緩沖(insert buffer)，只針對insert做了優化;現在對delete和update也有效，叫做寫緩沖(change buffer)。

它是一種應用在非唯一普通索引頁(non-unique secondary index page)不在緩沖池中，對頁進行了寫操作，并不會立刻將磁盤頁加載到緩沖池，而僅僅記錄緩沖變更(buffer changes)，等未來數據被讀取時，再將數據合并(merge)恢復到緩沖池中的技術。寫緩沖的目的是降低寫操作的磁盤IO，提升數據庫性能。

畫外音：R了狗了，這個句子，好長。

InnoDB加入寫緩沖優化，上文“情況二”流程會有什么變化?

假如要修改頁號為40的索引頁，而這個頁正好不在緩沖池內。

加入寫緩沖優化后，流程優化為：

• 在寫緩沖中記錄這個操作，一次內存操作;
• 寫入redo log，一次磁盤順序寫操作;

其性能與，這個索引頁在緩沖池中，相近。

畫外音：可以看到，40這一頁，并沒有加載到緩沖池中。

是否會出現一致性問題呢?

也不會。

• 數據庫異常奔潰，能夠從redo log中恢復數據;
• 寫緩沖不只是一個內存結構，它也會被定期刷盤到寫緩沖系統表空間;
• 數據讀取時，有另外的流程，將數據合并到緩沖池;

不妨設，稍后的一個時間，有請求查詢索引頁40的數據。

此時的流程如序號1-3：

• 載入索引頁，緩沖池未***，這次磁盤IO不可避免;
• 從寫緩沖讀取相關信息;
• 恢復索引頁，放到緩沖池LRU里;

畫外音：可以看到，40這一頁，在真正被讀取時，才會被加載到緩沖池中。

還有一個遺漏問題，為什么寫緩沖優化，僅適用于非唯一普通索引頁呢?

InnoDB里，聚集索引(clustered index)和普通索引(secondary index)的異同，《1分鐘了解MyISAM與InnoDB的索引差異》有詳盡的敘述，不再展開。

如果索引設置了唯一(unique)屬性，在進行修改操作時，InnoDB必須進行唯一性檢查。也就是說，索引頁即使不在緩沖池，磁盤上的頁讀取無法避免(否則怎么校驗是否唯一?)，此時就應該直接把相應的頁放入緩沖池再進行修改，而不應該再整寫緩沖這個幺蛾子。

除了數據頁被訪問，還有哪些場景會觸發刷寫緩沖中的數據呢?

還有這么幾種情況，會刷寫緩沖中的數據：

• 有一個后臺線程，會認為數據庫空閑時;
• 數據庫緩沖池不夠用時;
• 數據庫正常關閉時;
• redo log寫滿時;

畫外音：幾乎不會出現redo log寫滿，此時整個數據庫處于無法寫入的不可用狀態。

什么業務場景，適合開啟InnoDB的寫緩沖機制?

先說什么時候不適合，如上文分析，當：

• 數據庫都是唯一索引;
• 或者，寫入一個數據后，會立刻讀取它;

這兩類場景，在寫操作進行時(進行后)，本來就要進行進行頁讀取，本來相應頁面就要入緩沖池，此時寫緩存反倒成了負擔，增加了復雜度。

什么時候適合使用寫緩沖，如果：

• 數據庫大部分是非唯一索引;
• 業務是寫多讀少，或者不是寫后立刻讀取;

可以使用寫緩沖，將原本每次寫入都需要進行磁盤IO的SQL，優化定期批量寫磁盤。

畫外音：例如，賬單流水業務。

上述原理，對應InnoDB里哪些參數?

有兩個比較重要的參數。

• 參數：innodb_change_buffer_max_size
• 介紹：配置寫緩沖的大小，占整個緩沖池的比例，默認值是25%，***值是50%。

畫外音：寫多讀少的業務，才需要調大這個值，讀多寫少的業務，25%其實也多了。

• 參數：innodb_change_buffering
• 介紹：配置哪些寫操作啟用寫緩沖，可以設置成all/none/inserts/deletes等。

希望大家有收獲，思路比結論重要。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文