執(zhí)行insert語(yǔ)句之后插入的數(shù)據(jù)會(huì)不會(huì)立馬保存在磁盤(pán)中

這么一個(gè)問(wèn)題：當(dāng)你執(zhí)行一條insert語(yǔ)句之后，插入的數(shù)據(jù)就立馬保存在磁盤(pán)中了么？

答案是不一定！

下面我們來(lái)看一下insert語(yǔ)句在寫(xiě)入磁盤(pán)的過(guò)程中是如何的!

我們都知道數(shù)據(jù)在提交到數(shù)據(jù)庫(kù)中會(huì)有事務(wù)這一步，所以我們可以分兩步來(lái)看

一、提交事務(wù)前

1、首先進(jìn)入server層對(duì)sql會(huì)進(jìn)行一些必要的檢查，不會(huì)涉及到磁盤(pán)的寫(xiě)入。

2、進(jìn)入引擎層開(kāi)始正式提交執(zhí)行數(shù)據(jù)。

這里我們首先來(lái)了解一下MySQL在InnoDB存儲(chǔ)引擎中，數(shù)據(jù)是怎么存儲(chǔ)的!

同大多數(shù)數(shù)據(jù)庫(kù)一樣，InnoDB有頁(yè)（Page)的概念（也可以稱為塊）,頁(yè)是InnoDB磁盤(pán)管理的最小單位。在InnoDB存儲(chǔ)引擎中，默認(rèn)每個(gè)頁(yè)的大小為16 KB。而從InnoDB 1.2.x版本開(kāi)始，可以通過(guò)參數(shù)InnoDB_page_size將頁(yè)的大小設(shè)置為4 K、8 K、16 K。若設(shè)置完成，則所有表中頁(yè)的大小都為InnoDBpagesize,不可以對(duì)其再次進(jìn)行修改。除非通過(guò)mysqldump導(dǎo)入和導(dǎo)出操作來(lái)產(chǎn)生新的庫(kù)。

InnoDB的數(shù)據(jù)是按數(shù)據(jù)頁(yè)為單位來(lái)讀寫(xiě)的。也就是說(shuō)，當(dāng)需要讀一條記錄的時(shí)候，并不是將這個(gè)記錄本身從磁盤(pán)讀出來(lái)，而是以頁(yè)為單位，將其整體讀入內(nèi)存。

而將數(shù)據(jù)從磁盤(pán)讀入內(nèi)存涉及隨機(jī)IO的訪問(wèn)，是數(shù)據(jù)庫(kù)里面成本最高的操作之一，所以為了減少磁盤(pán)IO，InnoDB設(shè)計(jì)了change buffer這個(gè)機(jī)制。

什么叫做change buffer：

①在MySQL 5.5之前的版本中，由于只支持緩存insert操作，所以最初叫做insert buffer，只是后來(lái)的版本中支持了更多的操作類型緩存，才改叫change Buffer，這也是為什么代碼中有大量的ibuf前綴開(kāi)頭的函數(shù)或變量。

然而使用寫(xiě)緩沖需要同時(shí)滿足兩個(gè)條件：

(1) 索引是輔助索引

插入聚簇索引一般是順序的，一般不需要磁盤(pán)的隨機(jī)讀取，所以不需要使用change Buffer

(2) 索引不是唯一的

輔助索引不能是唯一的，因?yàn)樵诓迦刖彌_時(shí)，數(shù)據(jù)庫(kù)并不去查找索引頁(yè)來(lái)判斷插入的記錄的唯一性。如果去查找肯定又會(huì)有離散讀取的情況發(fā)生，從而導(dǎo)致change buffer失去了意義。

②change Buffer的底層實(shí)現(xiàn)

change Buffer底層結(jié)構(gòu)是一顆全局的B+樹(shù)，負(fù)責(zé)對(duì)所有的表空間進(jìn)行change Buffer。

所以insert語(yǔ)句并不需要立刻將數(shù)據(jù)寫(xiě)入磁盤(pán)文件中，只需要修改內(nèi)存緩沖池當(dāng)中對(duì)應(yīng)的數(shù)據(jù)頁(yè)就可以了。

4、都知道內(nèi)存不能保證數(shù)據(jù)的持久化，如果數(shù)據(jù)庫(kù)在這個(gè)過(guò)程中宕機(jī)了，怎么保證保存在緩存中的數(shù)據(jù)不丟失。redo log 因此而生，默認(rèn)情況下每次事務(wù)提交都會(huì)觸發(fā)一次 redo log 刷盤(pán)。

5、如果開(kāi)啟了 binlog 日志，事務(wù)邏輯數(shù)據(jù)將會(huì)被寫(xiě)入 binlog 文件，且為了保證復(fù)制安全，建議設(shè)置為每次事務(wù)提交時(shí)，都要將 binlog 日志的變更刷入磁盤(pán)。

綜上insert語(yǔ)句成功提交時(shí)，數(shù)據(jù)不是發(fā)生立馬磁盤(pán)數(shù)據(jù)寫(xiě)入的，而是通過(guò) redo log 和 binlog 文件最后把數(shù)據(jù)寫(xiě)入到磁盤(pán)。然而數(shù)據(jù)庫(kù)緩存區(qū)不可能無(wú)限大，redo log 也很難容下所有的數(shù)據(jù)，那緩存區(qū)的數(shù)據(jù)怎么寫(xiě)到磁盤(pán)中呢？

二、事務(wù)提交后

1、當(dāng)緩沖池中的數(shù)據(jù)頁(yè)達(dá)到一定量或數(shù)據(jù)庫(kù)的IO壓力較小時(shí)，都會(huì)進(jìn)行數(shù)據(jù)頁(yè)刷盤(pán)操作。

2、當(dāng)開(kāi)啟共享表空間時(shí)，刷新數(shù)據(jù)時(shí)首先會(huì)復(fù)制一份刷入共享表空間中，由于共享表空間的頁(yè)是連續(xù)的，對(duì)磁盤(pán)的寫(xiě)入也是順序操作，所以這個(gè)過(guò)程對(duì)性能消耗不大。

3、不管是否經(jīng)過(guò)共享表空間，更新的數(shù)據(jù)頁(yè)最終還是需要刷入表空間的數(shù)據(jù)文件。刷入完成后才能釋放數(shù)據(jù)庫(kù)緩存當(dāng)中的空間。

4、change Buffer也是數(shù)據(jù)庫(kù)緩存中的一部分，當(dāng)數(shù)據(jù)庫(kù)緩存空間不足需要交換出部分?jǐn)?shù)據(jù)更新頁(yè)時(shí)，有可能將寫(xiě)緩沖的數(shù)據(jù)頁(yè)換出，刷入共享表空間中的 change Buffer數(shù)據(jù)文件中。

5、當(dāng) innodb_stats_persistent=ON 時(shí)，插入語(yǔ)句所涉及到的數(shù)據(jù)就會(huì)被刷盤(pán)到 innodb_table_stats 和 innodbi_ndex_stats 這兩張系統(tǒng)表中。

綜上，一條 insert 語(yǔ)句的所有涉及到的數(shù)據(jù)在磁盤(pán)上會(huì)依次寫(xiě)入 redo log，binlog，共享表空間，最后在自己的用戶表空間落定為安。

延伸:

說(shuō)了數(shù)據(jù)寫(xiě)入到磁盤(pán)，那么change Buffer中的記錄何時(shí)合并（merge)到真正的輔助索引中呢？

從上文可知Change Buffer是一棵B+樹(shù)。當(dāng)需要實(shí)現(xiàn)插入記錄的輔助索引頁(yè)不在緩沖池中，輔助索引記錄首先會(huì)插入到這棵B+樹(shù)中。

merge操作可能發(fā)生在以下幾種情況下：

①輔助索引頁(yè)被讀到緩存中

②Change buffer bitmap頁(yè)追蹤到的輔助頁(yè)已無(wú)可用空間

③master thread工作

第一種情況為當(dāng)輔助索引頁(yè)被讀取到緩沖池中時(shí)，例如這在執(zhí)行正常的SELECT查詢操作，這時(shí)需要檢查Insert Buffer Bitmap頁(yè)，然后確認(rèn)該輔助索引頁(yè)是否有記錄存放于Insert Buffer B+樹(shù)中。若有，則將Insert Buffer B+樹(shù)中該頁(yè)的記錄插入到該輔助索引頁(yè)中。對(duì)該頁(yè)多次的記錄操作通過(guò)幾次操作合并到了原有的輔助索引頁(yè)中，因此性能會(huì)有大幅提高。

第二種情況Insert Buffer Bitmap 頁(yè)用來(lái)追蹤每個(gè)輔助索引頁(yè)的可用空間，并至少有1/32頁(yè)的空間。若插入輔助索引記錄時(shí)檢測(cè)到插入記錄后可用空間會(huì)小于1/32頁(yè)，則會(huì)強(qiáng)制進(jìn)行一個(gè)合并操作，即強(qiáng)制讀取輔助索引頁(yè)，將Insert Buffer B+樹(shù)中該頁(yè)的記錄及待插入的記錄插入到輔助索引頁(yè)中。這就是上述所說(shuō)的第二種情況。

第三種情況就是在Master Thread線程中每秒或每10秒會(huì)進(jìn)行一次Merge Change Buffer的操作，不同之處在于根據(jù)線程的工作狀態(tài)每次進(jìn)行merge操作的頁(yè)的數(shù)量不同。