MySQL實戰45講之6 唯一索引和普通索引

change buffer和redo log的區別

很容易被混淆的兩個概念，都是為了減少磁碟的io操作，但是在更新一條語句的時候，其實是有先後順序的，也就是看此資料葉在不在記憶體中，

如果資料葉在記憶體中，那麼更新操作會先在redo log中更改資料，然後等空閒再寫磁碟，這樣減少寫磁碟。

但是如果資料葉不在記憶體中，會先將操作指令存入change buffer（待更改的緩衝區）中，這時會先不更新資料，而是等到做查詢資料的時候的時候，資料葉讀到記憶體中後，再從change buffer拿到指令，並在記憶體中更新。等空閒時再刷到磁碟，

所以是否會change buffer是有前提條件，也就是該資料葉是否在記憶體中。先redolog 然後在判斷是否change buffer。

所以，如果要簡單地對比這兩個機制在提公升更新效能上的收益的話，redo log 主要節省的是隨機寫磁碟的 io 消耗**成順序寫），而 change buffer 主要節省的則是隨機讀磁碟的 io 消耗。

並且change buffer的作用是可以拆分一條語句的，比如說在插入一條資料的時候，主鍵和其他唯一索引的值不會做change buffer，但是其他欄位是可以走change buffer的。

選擇普通索引還是唯一索引？

對於查詢過程來說：

a、普通索引，查到滿足條件的第乙個記錄後，繼續查詢下乙個記錄，知道第乙個不滿足條件的記錄

b、唯一索引，由於索引唯一性，查到第乙個滿足條件的記錄後，停止檢索

但是，兩者的效能差距微乎其微。因為innodb根據資料頁來讀寫的。

對於更新過程來說：

概念：change buffer

當需要更新乙個資料頁，如果資料頁在記憶體中就直接更新，如果不在記憶體中，在不影響資料一致性的前提下，innodb會將這些更新操作快取在change buffer中。下次查詢需要訪問這個資料頁的時候，將資料頁讀入記憶體，然後執行change buffer中的與這個頁有關的操作。

change buffer是可以持久化的資料。在記憶體中有拷貝，也會被寫入到磁碟上

purge:將change buffer中的操作應用到原資料頁上，得到最新結果的過程，成為purge

訪問這個資料頁會觸發purge，系統有後台執行緒定期purge，在資料庫正常關閉的過程中，也會執行purge

唯一索引的更新不能使用change buffer

change buffer用的是buffer pool裡的記憶體，change buffer的大小，可以通過引數innodb_change_buffer_max_size來動態設定。這個引數設定為50的時候，表示change buffer的大小最多只能占用buffer pool的50%。

將資料從磁碟讀入記憶體涉及隨機io的訪問，是資料庫裡面成本最高的操作之一。

change buffer 因為減少了隨機磁碟訪問，所以對更新效能的提公升很明顯。

change buffer使用場景

在乙個資料頁做purge之前，change buffer記錄的變更越多，收益就越大。

對於寫多讀少的業務來說，頁面在寫完以後馬上被訪問到的概率比較小，此時change buffer的使用效果最好。這種業務模型常見的就是賬單類、日誌類的系統。

反過來，假設乙個業務的更新模式是寫入之後馬上會做查詢，那麼即使滿足了條件，將更新先記錄在change buffer,但之後由於馬上要訪問這個資料頁，會立即觸發purge過程。

這樣隨機訪問io的次數不會減少，反而增加了change buffer的維護代價。所以，對於這種業務模式來說，change buffer反而起到了***。

索引的選擇和實踐：

盡可能使用普通索引。

redo log主要節省的是隨機寫磁碟的io消耗(轉成順序寫)，而change buffer主要節省的則是隨機讀磁碟的io消耗。