當需要更新一個數(shù)據(jù)頁時，如果數(shù)據(jù)頁在內(nèi)存(buffer pool)中就直接更新好了(還要記下redo log)，
但是 如果這個數(shù)據(jù)頁還沒有在內(nèi)存中,并且不是唯一索引不用查是不是重了, InooDB 會將這些更新操作緩存在 change buffer 中(同樣要記下redo log),
這樣就不需要 從磁盤中 讀入這個數(shù)據(jù)頁了來更新了
好處:
- 語句的執(zhí)行速度會得到明顯的提升。
- 數(shù)據(jù)讀入內(nèi)存是需要占用 buffer pool 的，還能夠避免占用內(nèi)存，提高內(nèi)存利用率。
雖然名字叫作 change buffer，實際上它是可以持久化的數(shù)據(jù)。也就是說，change buffer 在內(nèi)存中有拷貝，也會被寫入到磁盤上。
將 change buffer 中的操作應用到原數(shù)據(jù)頁，得到最新結果的過程稱為 merge。
時機是:
- 訪問這個數(shù)據(jù)頁會觸發(fā) merge
- 系統(tǒng)有后臺線程會定期 merge。
- 在數(shù)據(jù)庫正常關閉（shutdown）的過程中，會執(zhí)行 merge 操作。
使用場景
change buffer 只限于用在普通索引的場景下，而不適用于唯一索引。
對唯一索引, 必須先查詢看有沒有已經(jīng)存在, 才能改, 所以必須先把數(shù)據(jù)從磁盤讀入內(nèi)存, 這步不能省
那么，現(xiàn)在有一個問題就是：普通索引的所有場景，使用 change buffer 都可以起到加速作用嗎？
merge 的時候是真正進行數(shù)據(jù)更新的時刻，而 change buffer 的主要目的就是將記錄的變更動作緩存下來，所以在一個數(shù)據(jù)頁做 merge 之前，change buffer 記錄的變更越多（也就是這個頁面上要更新的次數(shù)越多），收益就越大。
因此，對于寫多讀少的業(yè)務來說，頁面在寫完以后馬上被訪問到的概率比較小，此時 change buffer 的使用效果最好。
常見的就是 賬單類、日志類的系統(tǒng)。
反過來，寫入之后馬上會做查詢，那么即使?jié)M足了條件，將更新先記錄在 change buffer，立即觸發(fā) merge 過程。
隨機訪問 IO 的次數(shù)不會減少，反而增加了 change buffer 的維護代價。
和 redo log 一起看
表t 在k上有普通索引,以下只查id和k 是覆蓋索引
insert into t(id,k) values(id1,k1),(id2,k2);
假設k1 所在的數(shù)據(jù)頁在內(nèi)存 (InnoDB buffer pool) 中，k2 所在的數(shù)據(jù)頁不在
1.k1 所在的Page 1 在內(nèi)存中，直接更新內(nèi)存；
2.k2 所在的Page 2 沒有在內(nèi)存中，就在內(nèi)存(change buffer區(qū)域)記錄下“我要往 Page 2 插入一行”這個信息(省了讀磁盤了)
3.4. 將上述兩個動作記入 redo log 中(就這么一次順序?qū)懘疟P)
發(fā)現(xiàn), 執(zhí)行這條更新語句的成本很低，就是寫了兩處內(nèi)存，然后寫了一處磁盤（兩次操作合在一起寫了一次磁盤），而且還是順序?qū)懙摹?/p>
圖中的兩個虛線箭頭，是后臺操作(空閑時或者必須時寫入磁盤)，不影響更新的響應時間。
接著要讀取這2個剛更新的行
select * from t where k in (k1, k2)
k1 本來就在內(nèi)存中, 之前內(nèi)存也更新了, 所以直接拿內(nèi)存的就是對的
k2 只有id和k 在內(nèi)存的change buffer區(qū)域, 其他列的數(shù)據(jù)不在, 所以必須讀磁盤, 然后和change buffer區(qū)域記錄的修改過的最新數(shù)據(jù)結合, 返回正確數(shù)據(jù)(這會觸發(fā)change buffer的一次merge)
redo log 節(jié)省的是隨機寫磁盤的 IO 消耗（雖然也是磁盤,但是轉(zhuǎn)成順序?qū)懭罩荆?br> change buffer要節(jié)省隨機讀磁盤的 IO 消耗。如果沒有它, 要先把數(shù)據(jù)從磁盤讀入內(nèi)存, 再在內(nèi)存改, 有他省了一步
