建站
咨詢
售后
建站咨詢
新聞中心
上篇《??MySQL緩沖池(buffer pool)，終于懂了??》，介紹了InnoDB緩沖池的工作原理。
創(chuàng)新互聯(lián)公司堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站制作、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的古丈網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
簡單回顧一下：
- MySQL數(shù)據(jù)存儲包含內(nèi)存與磁盤兩個部分；
- 內(nèi)存緩沖池(buffer pool)以頁為單位，緩存最熱的數(shù)據(jù)頁(data page)與索引頁(index page)；
- InnoDB以變種LRU算法管理緩沖池，并能夠解決“預(yù)讀失效”與“緩沖池污染”的問題；
毫無疑問，對于讀請求，緩沖池能夠減少磁盤IO，提升性能。問題來了，那寫請求呢？
情況一
假如要修改頁號為4的索引頁，而這個頁正好在緩沖池內(nèi)。
如上圖序號1-2：
- 直接修改緩沖池中的頁，一次內(nèi)存操作；
- 寫入redo log，一次磁盤順序?qū)懖僮鳎?/li>
這樣的效率是最高的。
畫外音：像寫日志這種順序?qū)?，每秒幾萬次沒問題。
是否會出現(xiàn)一致性問題呢？
并不會。
- 讀取，會命中緩沖池的頁；
- 緩沖池LRU數(shù)據(jù)淘汰，會將“臟頁”刷回磁盤；
- 數(shù)據(jù)庫異常奔潰，能夠從redo log中恢復(fù)數(shù)據(jù)；
什么時候緩沖池中的頁，會刷到磁盤上呢？
定期刷磁盤，而不是每次刷磁盤，能夠降低磁盤IO，提升MySQL的性能。
畫外音：批量寫，是常見的優(yōu)化手段。
情況二
假如要修改頁號為40的索引頁，而這個頁正好不在緩沖池內(nèi)。
此時麻煩一點(diǎn)，如上圖需要1-3：
- 先把需要為40的索引頁，從磁盤加載到緩沖池，一次磁盤隨機(jī)讀操作；
- 修改緩沖池中的頁，一次內(nèi)存操作；
- 寫入redo log，一次磁盤順序?qū)懖僮鳎?/li>
沒有命中緩沖池的時候，至少產(chǎn)生一次磁盤IO，對于寫多讀少的業(yè)務(wù)場景，是否還有優(yōu)化的空間呢？
這即是InnoDB考慮的問題，又是本文將要討論的寫緩沖(change buffer)。
畫外音：從名字容易看出，寫緩沖是降低磁盤IO，提升數(shù)據(jù)庫寫性能的一種機(jī)制。
什么是InnoDB的寫緩沖？
在MySQL5.5之前，叫插入緩沖(insert buffer)，只針對insert做了優(yōu)化;現(xiàn)在對delete和update也有效，叫做寫緩沖(change buffer)。
它是一種應(yīng)用在非唯一普通索引頁(non-unique secondary index page)不在緩沖池中，對頁進(jìn)行了寫操作，并不會立刻將磁盤頁加載到緩沖池，而僅僅記錄緩沖變更(buffer changes)，等未來數(shù)據(jù)被讀取時，再將數(shù)據(jù)合并(merge)恢復(fù)到緩沖池中的技術(shù)。寫緩沖的目的是降低寫操作的磁盤IO，提升數(shù)據(jù)庫性能。
畫外音：R了狗了，這個句子，好長。
InnoDB加入寫緩沖優(yōu)化，上文“情況二”流程會有什么變化？
假如要修改頁號為40的索引頁，而這個頁正好不在緩沖池內(nèi)。
加入寫緩沖優(yōu)化后，流程優(yōu)化為：
- 在寫緩沖中記錄這個操作，一次內(nèi)存操作；
- 寫入redo log，一次磁盤順序?qū)懖僮鳎?/li>
其性能與，這個索引頁在緩沖池中，相近。
畫外音：可以看到，40這一頁，并沒有加載到緩沖池中。
是否會出現(xiàn)一致性問題呢？
也不會。
- 數(shù)據(jù)庫異常奔潰，能夠從redo log中恢復(fù)數(shù)據(jù)；
- 寫緩沖不只是一個內(nèi)存結(jié)構(gòu)，它也會被定期刷盤到寫緩沖系統(tǒng)表空間；
- 數(shù)據(jù)讀取時，有另外的流程，將數(shù)據(jù)合并到緩沖池；
不妨設(shè)，稍后的一個時間，有請求查詢索引頁40的數(shù)據(jù)。
此時的流程如序號1-3：
- 載入索引頁，緩沖池未命中，這次磁盤IO不可避免；
- 從寫緩沖讀取相關(guān)信息；
- 恢復(fù)索引頁，放到緩沖池LRU里；
畫外音：可以看到，40這一頁，在真正被讀取時，才會被加載到緩沖池中。
還有一個遺漏問題，為什么寫緩沖優(yōu)化，僅適用于非唯一普通索引頁呢？
InnoDB里，聚集索引(clustered index)和普通索引(secondary index)的異同，《??1分鐘了解MyISAM與InnoDB的索引差異??》有詳盡的敘述，不再展開。
如果索引設(shè)置了唯一(unique)屬性，在進(jìn)行修改操作時，InnoDB必須進(jìn)行唯一性檢查。也就是說，索引頁即使不在緩沖池，磁盤上的頁讀取無法避免(否則怎么校驗是否唯一？)，此時就應(yīng)該直接把相應(yīng)的頁放入緩沖池再進(jìn)行修改，而不應(yīng)該再整寫緩沖這個幺蛾子。
除了數(shù)據(jù)頁被訪問，還有哪些場景會觸發(fā)刷寫緩沖中的數(shù)據(jù)呢？
還有這么幾種情況，會刷寫緩沖中的數(shù)據(jù)：
- 有一個后臺線程，會認(rèn)為數(shù)據(jù)庫空閑時；
- 數(shù)據(jù)庫緩沖池不夠用時；
- 數(shù)據(jù)庫正常關(guān)閉時；
- redo log寫滿時；
畫外音：幾乎不會出現(xiàn)redo log寫滿，此時整個數(shù)據(jù)庫處于無法寫入的不可用狀態(tài)。
什么業(yè)務(wù)場景，適合開啟InnoDB的寫緩沖機(jī)制？
先說什么時候不適合，如上文分析，當(dāng)：
- 數(shù)據(jù)庫都是唯一索引；
- 或者，寫入一個數(shù)據(jù)后，會立刻讀取它；
這兩類場景，在寫操作進(jìn)行時(進(jìn)行后)，本來就要進(jìn)行進(jìn)行頁讀取，本來相應(yīng)頁面就要入緩沖池，此時寫緩存反倒成了負(fù)擔(dān)，增加了復(fù)雜度。
什么時候適合使用寫緩沖，如果：
- 數(shù)據(jù)庫大部分是非唯一索引；
- 業(yè)務(wù)是寫多讀少，或者不是寫后立刻讀?。?/li>
可以使用寫緩沖，將原本每次寫入都需要進(jìn)行磁盤IO的SQL，優(yōu)化定期批量寫磁盤。
畫外音：例如，賬單流水業(yè)務(wù)。
上述原理，對應(yīng)InnoDB里哪些參數(shù)？
有兩個比較重要的參數(shù)。
(1) 參數(shù)：innodb_change_buffer_max_size
介紹：配置寫緩沖的大小，占整個緩沖池的比例，默認(rèn)值是25%，最大值是50%。
畫外音：寫多讀少的業(yè)務(wù)，才需要調(diào)大這個值，讀多寫少的業(yè)務(wù)，25%其實也多了。
(2) 參數(shù)：innodb_change_buffering
介紹：配置哪些寫操作啟用寫緩沖，可以設(shè)置成all/none/inserts/deletes等。
希望大家有收獲，思路比結(jié)論重要。
分享文章：MySQL寫緩沖(change buffer)，終于懂了?。。。ㄊ詹兀?
文章網(wǎng)址：http://www.dlmjj.cn/article/cdehoeo.html
