我們知道在進行插入操作時，資料頁的存放還是按主鍵id的執行順序存放， 但是對於非聚集索引，葉子節點的插入不再是順序的了。
例如,對於如下表結構進行insert操作
create table tab (
id int auto_increment,
name varchar(30),
primary key (id),
key(name)
) engine=innodb default charset=utf8;
nanme 為非唯一字段，這時就需要離散地訪問非聚集索引頁，插入效能在這裡變低了。然而這並不是這個name欄位上索引的錯誤，因為b+樹的特性決定了非聚集索引插入的離散性。
為了解決非聚族索引的隨機寫效能差,innodb 儲存引擎開發了 innsert-buffer pool (5.5 中做了加強,稱之為 change buffer pool)
一 什麼是 innsert-buffer pool
innodb使用insert buffer"欺騙"資料庫:對於為非唯一索引，輔助索引的修改操作並非實時更新索引的葉子頁,而是把若干對同一頁面的更新快取起來做合併為一次性更新操作,轉化隨機io 為順序io,這樣可以避免隨機io帶來效能損耗，提高資料庫的寫效能。
1.1 原理:
a 先判斷要更新的這一頁在不在記憶體中。
b 如果不在,則讀取index page 存入insert buffer，按照master thread的排程規則來合併非唯一索引和索引頁中的葉子結點.
a 主動merger[innodb主線程定期完成，使用者執行緒無感知]
主動merger：
原理:主動merge通過innodb主線程(svr_master_thread）判斷：若過去1s之內發生的i/o小於系統i/o能力的5%，
則主動進行一次insert buffer的meger操作。meger的頁面數為系統i/o能力的5%，讀取採用async io模式。
每10s,必定觸發一次insert buffer meger操作。meger的頁面數仍舊為系統 i/o能力的5%。
步驟:1.主線程發出async io請求，async讀取需要被meger的索引頁面
2.i/o handler 執行緒，在接受到完成的async i/o之後，進行merger
b 被動merge[使用者執行緒完成，使用者能感受到meger操作帶來的效能影響]
被動merge:
情況一：
insert操作，導致頁面空間不足，需要**(split)。由於insert buffer只針對單個頁面，不能buffer page split[頁已經在記憶體裡]，因此引起頁面的被動meger。同理，update操作導致頁面空間不 足；purge導致頁面為空等。總之:若 當前操作引起頁面split or
merge,那麼就會導致被動merge。
情況二:
insert操作，由於其它各種原因，insert buffer優化返回false，需要真正讀取page時，要進行被動merge。與一不同的是，頁在disk上，需要讀取到記憶體裡。
情況三：
在進行insert buffer操作，發現insert buffer太大，需要壓縮insert buffer,這時需要強制被動merge,不允許 insert 操作進行。
因為
2 寫唯一索引要檢查記錄是不是存在，所以在修改唯一索引之前,必須把修改的記錄相關的索引頁讀出來才知道是不是唯一,這樣insert buffer就沒意義了，反正要讀出來(讀帶來隨機io)，所以只對非唯一索引有效。
我們可以通過show engine innodb status \g 來檢視插入緩衝的資訊
-------------------------------------
insert buffer and adaptive hash index
-------------------------------------
ibuf: size 1, free list len 0, seg size 2, 2920 merges
merged operations:
insert 23858, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
seg size顯示了當前插入緩衝的大小為2 *16kb，大約為32kb，free list len代表了空閒列表的長度，size代表了已經合併記錄頁的數量。merges 表示合併次數。
merged operations:
inserts代表插入的記錄數，delete mark delete 次數均為0.
change buffering 是mysql5.5加入的新特性，change buffering是insert buffer的加強，insert buffer只針對insert有效，change buffering對insert、delete、update(delete+insert)、purge都有效。當修改乙個索引塊(secondary index)時的資料時，索引塊在buffter pool中不存在，修改資訊就會被cache在change buffer中，當通過索引掃瞄把需要的索引塊讀取到buffer pool時，會和change buffer中修改資訊合併，再擇機寫回disk。目的還是為了減少隨機io帶來效能損耗，說明白了：把隨機io盡量變成順序io。對於廉價的機械硬碟，這個引數還是能幫助提高效能的。在ssd盛行的今天，在ssd上隨機訪問和順序訪問效能幾乎差不多的情況下，insert buffer/change buffering特性不會帶來多大的效能提公升。[1]
some
little
known
facts
about
innodb
insert
buffer
[2]innodb-performance-change_buffering
[3]mysql-5-5-innodb-change-buffering
[4]innodb的master
thread排程流程
InnoDB關鍵特性之double write
一 髒頁刷盤風險 關於io的最小單位 1 資料庫io的最小單位是16k mysql預設，oracle是8k 2 檔案系統io的最小單位是4k 也有1k的 3 磁碟io的最小單位是512k 因此，存在io寫入導致page損壞的風險 二 doublewrite 兩次寫 提高innodb的可靠性，用來解決...
InnoDB關鍵特性
innodb使用insert buffer 欺騙 資料庫 對於為非唯一索引，輔助索引的修改操作並非實時更新索引的葉子頁,而是把若干對同一頁面的更新快取起來做合併為一次性更新操作,轉化隨機io 為順序io,這樣可以避免隨機io帶來效能損耗，提高資料庫的寫效能。ibuf pool size per ma...
innodb 關鍵特性
插入緩衝 innodb儲存引擎對於非聚集索引的插入或更新操作，不是每一次直接插入到索引頁中，而是先判斷插入的非聚集索引頁是否在緩衝池，若在，則直接插入 不在，則先放在乙個insert buffer物件中。資料庫這個非聚集的索引已經插到葉子節點，而實際並沒有，知識存放在另乙個位置。然後再以一定的頻率和...