今天在做一個大業務的數據刪除時，看到下面的性能曲線圖

在刪除動作開始之后，insert buffer 大小增加到140。對于這些狀態參數的說明

InnoDB Insert Buffer

插入緩沖,并不是緩存的一部分,而是物理頁,對于非聚集索引的插入或更新操作,不是每一次直接插入索引頁.而是先判斷插入的非聚集索引頁是否在緩沖池中.如果在,則直接插入,如果不再,則先放入一個插入緩沖區中.然后再以一定的頻率執行插入緩沖和非聚集索引頁子節點的合并操作.

使用條件:非聚集索引,非唯一

Ibuf Inserts

插入的記錄數

Ibuf Merged

合并的頁的數量

Ibuf Merges

合并的次數

如果merges/merged的值等于3/1,則代表插入緩沖對于非聚集索引頁的IO請求大約降低了3倍

InnoDB Insert Buffer Usage

Ibuf Cell Count

分段大小

Ibuf Used Cells

插入緩沖區的大小

Ibuf Free Cells"自由列表"的長度

可以這樣理解，在平時正常業務下，需要合并的二級索引基本沒有，在做批量大刪除的時候，產生了很多需要合并的二級索引改變。

看看合并操作節省了多少IO請求,(1034310+3)/113909=9.08,

-------------------------------------INSERT BUFFER AND ADAPTIVE HASH INDEX-------------------------------------Ibuf: size1, free list len 134, seg size 136, 113909merges

merged operations:

insert3, delete mark 2319764, delete 1034310discarded operations:

insert0, delete mark 0, delete 0Hash table size288996893, node heap has 304687buffer(s)1923.58 hash searches/s, 1806.60 non-hash searches/s

摘錄一段朋友博客上對于insert buffer的說明

一，插入緩沖(Insert Buffer/Change Buffer)：提升插入性能

只對于非聚集索引(非唯一)的插入和更新有效，對于每一次的插入不是寫到索引頁中，而是先判斷插入的非聚集索引頁是否在緩沖池中，如果在則直接插入；若不在，則先放到Insert Buffer 中，再按照一定的頻率進行合并操作。這樣通常能將多個插入合并到一個操作中，提升插入性能。使用插入緩沖的條件：*非聚集索引*非唯一

插入緩沖最大使用空間為1/2的緩沖池大小，不能調整大小，在plugin innodb中，升級成了Change Buffer。不僅對insert，對update、delete都有效。其參數是：

innodb_change_buffering，設置的值有：inserts、deletes、purges、changes(inserts和deletes)、all(默認)、none。

可以通過參數控制其使用的大小：

innodb_change_buffer_max_size，默認是25，即緩沖池的1/4。最大可設置為50。在5.6中被引入。

上面提過在一定頻率下進行合并，那所謂的頻率是什么條件？1)輔助索引頁被讀取到緩沖池中。正常的select先檢查Insert Buffer是否有該非聚集索引頁存在，若有則合并插入。2)輔助索引頁沒有可用空間。空間小于1/32頁的大小，則會強制合并操作。3)Master Thread 每秒和每10秒的合并操作。

innodb buffer pool 包含的數據頁類型有：索引頁，數據頁，undo頁，插入緩沖(insert buffer),自適應哈希索引，innodb存儲是鎖信息，數據字典信息等，結構圖如下

有幾個問題需要回答

1：為什么會有insert buffer,insert buffer能幫我們解決什么問題？

2：insert buffer有什么限制，為什么會有這些限制？

先說第一個問題。

舉個現實中的例子來做說明，我們去圖書館還書，對應圖書館來說，他是做了insert(增加)操作，管理員在1小時內接受了100本書，這時候他有2種做法把還回來的書歸位到書架上

1)每還回來一本書，根據這本書的編碼(書柜區-排-號)把書送回架上

2)暫時不做歸位操作，先放到柜面上，等不忙的時候，再把這些書按照書柜區-排-號先排好，然后一次性歸位

用方法1，管理員需要進出(IO)藏書區100次，不停的登高爬低完成圖書歸位操作，累死累活，效率很差。

用方法2，管理員只需要進出(IO)藏書區1次，對同一個位置的書，不管多少，都只要爬一次樓梯，大大減輕了管理員的工作量。

所以圖書館都是按照方法2來做還書動作的。但是你要說，我的圖書館就20本書，1個0.5米的架子，方法2和1管理起來都很方便，這種情況不在我們討論的范圍。當數據量非常小的時候，就不存在效率問題了。

關系數據庫在處理插入操作的時候，處理的方法和上面類似，每一次插入都相當于還一本書，它也需要一個柜臺來保存插入的數據，然后分類歸檔，在不忙的時候做批量的歸位。這個柜臺就是insert buffer.

我想這就是為什么會有insert buffer，更多的是處于性能優化的考慮。

再說第二個問題，有什么限制：“只對于非聚集索引(非唯一)的插入和更新有效”

為什么對于非聚集索引(非唯一)的插入和更新有效?

還是用還書的例子來說，還一本書A到圖書館，管理員要判斷一下這本書是不是唯一的，他在柜臺上是看不到的，必須爬到指定位置去確認，這個過程其實已經產生了一次IO操作，相當于沒有節省任何操作。

所以這個buffer只能處理非唯一的插入，不要求判斷是否唯一。聚集索引就不用說了，它肯定是唯一的，mysql現在還只能通過主鍵聚集。

在MYSQL里面，insert buffer的大小在代碼里面設定的最大可以到整個innodb buffer pool size的50%。這其實是不科學的，能夠想象一下一個100平米的圖書館，有50平米是做退書的柜臺是什么樣子的嗎？

前面說到管理員圖書歸位的時候，他會選擇在“不忙的時候”再去做，優先處理前臺退書操作，這個在MYSQL里面是這樣體現的：

1)每1秒，如果IO次數小于5，合并插入緩沖。

2)每10秒，IO次數小于200，合并最多5個插入緩沖。

總結

以上是生活随笔為你收集整理的mysql 插入缓冲_innodb insert buffer 插入缓冲区的理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。