InnoDB存儲(chǔ)引擎的關(guān)鍵特性包括插入緩沖、兩次寫(xiě)（double write）、自適應(yīng)哈希索引（adaptive hash index）。這些特性為InnoDB存儲(chǔ)引擎帶來(lái)了更好的性能和更高的可靠性。

插入緩沖

插入緩沖是InnoDB存儲(chǔ)引擎關(guān)鍵特性中最令人激動(dòng)的。不過(guò)，這個(gè)名字可能會(huì)讓人認(rèn)為插入緩沖是緩沖池中的一個(gè)部分。其實(shí)不然，InnoDB緩沖池中有Insert Buffer信息固然不錯(cuò)，但是Insert Buffer和數(shù)據(jù)頁(yè)一樣，也是物理頁(yè)的一個(gè)組成部分。

主鍵是行唯一的標(biāo)識(shí)符，在應(yīng)用程序中行記錄的插入順序是按照主鍵遞增的順序進(jìn)行插入的。因此，插入聚集索引一般是順序的，不需要磁盤(pán)的隨機(jī)讀取。

比如說(shuō)我們按下列SQL定義的表：create table t（id int auto_increment,name varchar(30),primary key(id));

id列是自增長(zhǎng)的，這意味著當(dāng)執(zhí)行插入操作時(shí)，id列會(huì)自動(dòng)增長(zhǎng)，頁(yè)中的行記錄按id執(zhí)行順序存放。一般情況下，不需要隨機(jī)讀取另一頁(yè)執(zhí)行記錄的存放。因此，在這樣的情況下，插入操作一般很快就能完成。但是，不可能每張表上只有一個(gè)聚集索引，在更多的情況下，一張表上有多個(gè)非聚集的輔助索引（secondary index）。比如，我們還需要按照name這個(gè)字段進(jìn)行查找，并且name這個(gè)字段不是唯一的。

表是按如下的SQL語(yǔ)句定義的：create table t (id int auto_increment,name varchar(30)，primary key(id),key(name));

這樣的情況下產(chǎn)生了一個(gè)非聚集的并且不是唯一的索引。在進(jìn)行插入操作時(shí)，數(shù)據(jù)頁(yè)的存放還是按主鍵id的執(zhí)行順序存放，但是對(duì)于非聚集索引，葉子節(jié)點(diǎn)的插入不再是順序的了。這時(shí)就需要離散地訪(fǎng)問(wèn)非聚集索引頁(yè)，插入性能在這里變低了。然而這并不是這個(gè)name字段上索引的錯(cuò)誤，因?yàn)锽+樹(shù)的特性決定了非聚集索引插入的離散性。

InnoDB存儲(chǔ)引擎開(kāi)創(chuàng)性地設(shè)計(jì)了插入緩沖，對(duì)于非聚集索引的插入或更新操作，不是每一次直接插入索引頁(yè)中，而是先判斷插入的非聚集索引頁(yè)是否在緩沖池中。如果在，則直接插入；如果不在，則先放入一個(gè)插入緩沖區(qū)中，好似欺騙數(shù)據(jù)庫(kù)這個(gè)非聚集的索引已經(jīng)插到葉子節(jié)點(diǎn)了，然后再以一定的頻率執(zhí)行插入緩沖和非聚集索引頁(yè)子節(jié)點(diǎn)的合并操作，這時(shí)通常能將多個(gè)插入合并到一個(gè)操作中（因?yàn)樵谝粋€(gè)索引頁(yè)中），這就大大提高了對(duì)非聚集索引執(zhí)行插入和修改操作的性能。

插入緩沖的使用需要滿(mǎn)足以下兩個(gè)條件：

1.索引是輔助索引。

2.索引不是唯一的。

當(dāng)滿(mǎn)足以上兩個(gè)條件時(shí)，InnoDB存儲(chǔ)引擎會(huì)使用插入緩沖，這樣就能提高性能了。不過(guò)考慮一種情況，應(yīng)用程序執(zhí)行大量的插入和更新操作，這些操作都涉及了不唯一的非聚集索引，如果在這個(gè)過(guò)程中數(shù)據(jù)庫(kù)發(fā)生了宕機(jī)，這時(shí)候會(huì)有大量的插入緩沖并沒(méi)有合并到實(shí)際的非聚集索引中。如果是這樣，恢復(fù)可能需要很長(zhǎng)的時(shí)間，極端情況下甚至需要幾個(gè)小時(shí)來(lái)執(zhí)行合并恢復(fù)操作。

輔助索引不能是唯一的，因?yàn)樵诎阉迦氲讲迦刖彌_時(shí)，我們并不去查找索引頁(yè)的情況。如果去查找肯定又會(huì)出現(xiàn)離散讀的情況，插入緩沖就失去了意義。

查看插入緩沖的信息：

show engine innodb status\G

seg size顯示了當(dāng)前插入緩沖的大小為2*16KB，free list len代表了空閑列表的長(zhǎng)度，size代表了已經(jīng)合并記錄頁(yè)的數(shù)量。

下面一行可能是我們真正關(guān)心的，因?yàn)樗@示了提高性能了。inserts代表插入的記錄數(shù)，merged recs代表合并的頁(yè)的數(shù)量，merges代表合并的次數(shù)。

merged recs:merges大約為3:1，代表插入緩沖將對(duì)于非聚集索引頁(yè)的IO請(qǐng)求大約降低了3倍。

問(wèn)題：

目前插入緩沖存在一個(gè)問(wèn)題是，在寫(xiě)密集的情況下，插入緩沖會(huì)占用過(guò)多的緩沖池內(nèi)存，默認(rèn)情況下最大可以占用1/2的緩沖池內(nèi)存。Percona已發(fā)布一些patch來(lái)修正插入緩沖占用太多緩沖池內(nèi)存的問(wèn)題，具體的可以到http：//www.percona.com/percona-lab.html查找。簡(jiǎn)單來(lái)說(shuō)，修改IBUF_POOL_SIZE_PER_MAX_SIZE就可以對(duì)插入緩沖的大小進(jìn)行控制，例如，將IBUF_POOL_SIZE_PER_MAX_SIZE改為3，則最大只能使用1/3的緩沖池內(nèi)存。

兩次寫(xiě)

如果說(shuō)插入緩沖帶給InnoDB存儲(chǔ)引擎的是性能，那么兩次寫(xiě)帶給InnoDB存儲(chǔ)引擎的是數(shù)據(jù)的可靠性。當(dāng)數(shù)據(jù)庫(kù)宕機(jī)時(shí)，可能發(fā)生數(shù)據(jù)庫(kù)正在寫(xiě)一個(gè)頁(yè)面，而這個(gè)頁(yè)只寫(xiě)了一部分（比如16K的頁(yè)，只寫(xiě)前4K的頁(yè)）的情況，我們稱(chēng)之為部分寫(xiě)失效（partial page write）。在InnoDB存儲(chǔ)引擎未使用double write技術(shù)前，曾出現(xiàn)過(guò)因?yàn)椴糠謱?xiě)失效而導(dǎo)致數(shù)據(jù)丟失的情況。

有人也許會(huì)想，如果發(fā)生寫(xiě)失效，可以通過(guò)重做日志進(jìn)行恢復(fù)。這是一個(gè)辦法。但是必須清楚的是，重做日志中記錄的是對(duì)頁(yè)的物理操作，如偏移量800，寫(xiě)'aaaa'記錄。如果這個(gè)頁(yè)本身已經(jīng)損壞，再對(duì)其進(jìn)行重做是沒(méi)有意義的。這就是說(shuō)，在應(yīng)用（apply）重做日志前，我們需要一個(gè)頁(yè)的副本，當(dāng)寫(xiě)入失效發(fā)生時(shí)，先通過(guò)頁(yè)的副本來(lái)還原該頁(yè)，再進(jìn)行重做，這就是doublewrite。

InnoDB存儲(chǔ)引擎doublewrite的體系架構(gòu)如圖2-4所示

doublewrite由兩部分組成：一部分是內(nèi)存中的doublewrite buffer，大小為2MB；另一部分是物理磁盤(pán)上共享表空間中連續(xù)的128個(gè)頁(yè)，即兩個(gè)區(qū)（extent），大小同樣為2MB(頁(yè)的副本)。當(dāng)緩沖池的臟頁(yè)刷新時(shí)，并不直接寫(xiě)磁盤(pán)，而是會(huì)通過(guò)memcpy函數(shù)將臟頁(yè)先拷貝到內(nèi)存中的doublewrite buffer，之后通過(guò)doublewrite buffer再分兩次，每次寫(xiě)入1MB到共享表空間的物理磁盤(pán)上，然后馬上調(diào)用fsync函數(shù)，同步磁盤(pán)，避免緩沖寫(xiě)帶來(lái)的問(wèn)題。在這個(gè)過(guò)程中，因?yàn)閐oublewrite頁(yè)是連續(xù)的，因此這個(gè)過(guò)程是順序?qū)懙?，開(kāi)銷(xiāo)并不是很大。在完成doublewrite頁(yè)的寫(xiě)入后，再將doublewrite buffer中的頁(yè)寫(xiě)入各個(gè)表空間文件中，此時(shí)的寫(xiě)入則是離散的。

可以通過(guò)以下命令觀察到doublewrite運(yùn)行的情況： show global status like 'innodb_dblwr%'\G

doublewrite一共寫(xiě)了18 445個(gè)頁(yè)，但實(shí)際的寫(xiě)入次數(shù)為434，(42:1)   基本上符合64:1。

如果發(fā)現(xiàn)你的系統(tǒng)在高峰時(shí)Innodb_dblwr_pages_written:Innodb_dblwr_writes遠(yuǎn)小于64:1，那么說(shuō)明你的系統(tǒng)寫(xiě)入壓力并不是很高。

如果操作系統(tǒng)在將頁(yè)寫(xiě)入磁盤(pán)的過(guò)程中崩潰了，在恢復(fù)過(guò)程中，InnoDB存儲(chǔ)引擎可以從共享表空間中的doublewrite中找到改頁(yè)的一個(gè)副本，將其拷貝到表空間文件，再應(yīng)用重做日志。下面顯示了由doublewrite進(jìn)行恢復(fù)的一種情況： 

090924 11：36：32 mysqld restarted
090924 11：36：33 InnoDB：Database was not shut down normally！
InnoDB：Starting crash recovery.
InnoDB：Reading tablespace information from the.ibd files……
InnoDB：Error：space id in fsp header 0，but in the page header 4294967295
InnoDB：Error：tablespace id 4294967295 in file./test/t.ibd is not sensible
InnoDB：Error：tablespace id 0 in file./test/t2.ibd is not sensible
090924 11：36：33 InnoDB：Operating system error number 40 in a file operation.
InnoDB：Error number 40 means'Too many levels of symbolic links'.
InnoDB：Some operating system error numbers are described at
InnoDB：http：//dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
InnoDB：File name./now/member
InnoDB：File operation call：'stat'.
InnoDB：Error：os_file_readdir_next_file（）returned-1 in
InnoDB：directory./now
InnoDB：Crash recovery may have failed for some.ibd files！
InnoDB：Restoring possible half-written data pages from the doublewrite
InnoDB：buffer……

參數(shù)skip_innodb_doublewrite可以禁止使用兩次寫(xiě)功能，這時(shí)可能會(huì)發(fā)生前面提及的寫(xiě)失效問(wèn)題。不過(guò)，如果你有多臺(tái)從服務(wù)器（slave server），需要提供較快的性能（如slave上做的是RAID0），也許啟用這個(gè)參數(shù)是一個(gè)辦法。不過(guò)，在需要提供數(shù)據(jù)高可靠性的主服務(wù)器（master server）上，任何時(shí)候我們都應(yīng)確保開(kāi)啟兩次寫(xiě)功能。

注意：有些文件系統(tǒng)本身就提供了部分寫(xiě)失效的防范機(jī)制，如ZFS文件系統(tǒng)。在這種情況下，我們就不要啟用doublewrite了。 

自適應(yīng)哈希索引

哈希（hash）是一種非?？斓牟檎曳椒ǎ话闱闆r下查找的時(shí)間復(fù)雜度為O(1)。常用于連接（join）操作，如SQL Server和Oracle中的哈希連接（hash join）。但是SQL Server和Oracle等常見(jiàn)的數(shù)據(jù)庫(kù)并不支持哈希索引（hash index）。MySQL的Heap存儲(chǔ)引擎默認(rèn)的索引類(lèi)型為哈希，而InnoDB存儲(chǔ)引擎提出了另一種實(shí)現(xiàn)方法，自適應(yīng)哈希索引（adaptive hash index）。

InnoDB存儲(chǔ)引擎會(huì)監(jiān)控對(duì)表上索引的查找，如果觀察到建立哈希索引可以帶來(lái)速度的提升，則建立哈希索引，所以稱(chēng)之為自適應(yīng)（adaptive）的。自適應(yīng)哈希索引通過(guò)緩沖池的B+樹(shù)構(gòu)造而來(lái)，因此建立的速度很快。而且不需要將整個(gè)表都建哈希索引，InnoDB存儲(chǔ)引擎會(huì)自動(dòng)根據(jù)訪(fǎng)問(wèn)的頻率和模式來(lái)為某些頁(yè)建立哈希索引。

根據(jù)InnoDB的官方文檔顯示，啟用自適應(yīng)哈希索引后，讀取和寫(xiě)入速度可以提高2倍；對(duì)于輔助索引的連接操作，性能可以提高5倍。自適應(yīng)哈希索引是非常好的優(yōu)化模式，其設(shè)計(jì)思想是數(shù)據(jù)庫(kù)自?xún)?yōu)化（self-tuning），即無(wú)需DBA對(duì)數(shù)據(jù)庫(kù)進(jìn)行調(diào)整。

查看當(dāng)前自適應(yīng)哈希索引的使用狀況：show engine innodb status\G

現(xiàn)在可以看到自適應(yīng)哈希索引的使用信息了，包括自適應(yīng)哈希索引的大小、使用情況、每秒使用自適應(yīng)哈希索引搜索的情況。值得注意的是，哈希索引只能用來(lái)搜索等值的查詢(xún)，如select * from table where index_col='xxx'，而對(duì)于其他查找類(lèi)型，如范圍查找，是不能使用的。因此，這里出現(xiàn)了non-hash searches/s的情況。用hash searches:non-hash searches命令可以大概了解使用哈希索引后的效率。

由于自適應(yīng)哈希索引是由InnoDB存儲(chǔ)引擎控制的，所以這里的信息只供我們參考。不過(guò)我們可以通過(guò)參數(shù)innodb_adaptive_hash_index來(lái)禁用或啟動(dòng)此特性，默認(rèn)為開(kāi)啟。

以上這篇InnoDB的關(guān)鍵特性-插入緩存,兩次寫(xiě),自適應(yīng)hash索引詳解就是小編分享給大家的全部?jī)?nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。