InnoDB儲存引擎的關鍵特性包括插入緩衝、兩次寫（double write）、自適應雜湊索引（adaptive hash index）。這些特性為InnoDB儲存引擎帶來了更好的效能和更高的可靠性。

插入緩衝

插入緩衝是InnoDB儲存引擎關鍵特性中最令人激動的。不過，這個名字可能會讓人認為插入緩衝是緩衝池中的一個部分。其實不然，InnoDB緩衝池中有Insert Buffer資訊固然不錯，但是Insert Buffer和資料頁一樣，也是物理頁的一個組成部分。

主鍵是行唯一的識別符號，在應用程式中行記錄的插入順序是按照主鍵遞增的順序進行插入的。因此，插入聚集索引一般是順序的，不需要磁碟的隨機讀取。

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

id列是自增長的，這意味著當執行插入操作時，id列會自動增長，頁中的行記錄按id執行順序存放。一般情況下，不需要隨機讀取另一頁執行記錄的存放。因此，在這樣的情況下，插入操作一般很快就能完成。但是，不可能每張表上只有一個聚集索引，在更多的情況下，一張表上有多個非聚集的輔助索引（secondary index）。比如，我們還需要按照name這個欄位進行查詢，並且name這個欄位不是唯一的。

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

這樣的情況下產生了一個非聚集的並且不是唯一的索引。在進行插入操作時，資料頁的存放還是按主鍵id的執行順序存放，但是對於非聚集索引，葉子節點的插入不再是順序的了。這時就需要離散地訪問非聚集索引頁，插入效能在這裡變低了。然而這並不是這個name欄位上索引的錯誤，因為B+樹的特性決定了非聚集索引插入的離散性。

InnoDB儲存引擎開創性地設計了插入緩衝，對於非聚集索引的插入或更新操作，不是每一次直接插入索引頁中，而是先判斷插入的非聚集索引頁是否在緩衝池中。如果在，則直接插入；如果不在，則先放入一個插入緩衝區中，好似欺騙資料庫這個非聚集的索引已經插到葉子節點了，然後再以一定的頻率執行插入緩衝和非聚集索引頁子節點的合併操作

插入緩衝的使用需要滿足以下兩個條件：

1.索引是輔助索引。

2.索引不是唯一的。

當滿足以上兩個條件時，InnoDB儲存引擎會使用插入緩衝，這樣就能提高效能了。不過考慮一種情況，應用程式執行大量的插入和更新操作，這些操作都涉及了不唯一的非聚集索引，如果在這個過程中資料庫發生了宕機，這時候會有大量的插入緩衝並沒有合併到實際的非聚集索引中。如果是這樣，恢復可能需要很長的時間，極端情況下甚至需要幾個小時來執行合併恢復操作。

輔助索引不能是唯一的，因為在把它插入到插入緩衝時，我們並不去查詢索引頁的情況。如果去查詢肯定又會出現離散讀的情況，插入緩衝就失去了意義。

檢視插入緩衝的資訊：

show engine innodb status\G

seg size顯示了當前插入緩衝的大小為2*16KB，free list len代表了空閒列表的長度，size代表了已經合併記錄頁的數量。

下面一行可能是我們真正關心的，因為它顯示了提高效能了。inserts代表插入的記錄數，merged recs代表合併的頁的數量，merges代表合併的次數。

merged recs:merges大約為3:1，代表插入緩衝將對於非聚集索引頁的IO請求大約降低了3倍。

問題：

目前插入緩衝存在一個問題是，在寫密集的情況下，插入緩衝會佔用過多的緩衝池記憶體，預設情況下最大可以佔用1/2的緩衝池記憶體。Percona已釋出一些patch來修正插入緩衝佔用太多緩衝池記憶體的問題，具體的可以到http：//www.percona.com/percona-lab.html查詢。簡單來說，修改IBUF_POOL_SIZE_PER_MAX_SIZE就可以對插入緩衝的大小進行控制，例如，將IBUF_POOL_SIZE_PER_MAX_SIZE改為3，則最大隻能使用1/3的緩衝池記憶體。

兩次寫

如果說插入緩衝帶給InnoDB儲存引擎的是效能，那麼兩次寫帶給InnoDB儲存引擎的是資料的可靠性。當資料庫宕機時，可能發生資料庫正在寫一個頁面，而這個頁只寫了一部分（比如16K的頁，只寫前4K的頁）的情況，我們稱之為部分寫失效（partial page write）。在InnoDB儲存引擎未使用double write技術前，曾出現過因為部分寫失效而導致資料丟失的情況。

有人也許會想，如果發生寫失效，可以通過重做日誌進行恢復。這是一個辦法。但是必須清楚的是，重做日誌中記錄的是對頁的物理操作，如偏移量800，寫'aaaa'記錄。如果這個頁本身已經損壞，再對其進行重做是沒有意義的。這就是說，在應用（apply）重做日誌前，我們需要一個頁的副本，當寫入失效發生時，先通過頁的副本來還原該頁，再進行重做，這就是doublewrite。

InnoDB儲存引擎doublewrite的體系架構如圖2-4所示

doublewrite由兩部分組成：一部分是記憶體中的doublewrite buffer，大小為2MB；另一部分是物理磁碟上共享表空間中連續的128個頁，即兩個區（extent），大小同樣為2MB(頁的副本)。當緩衝池的髒頁重新整理時，並不直接寫磁碟，而是會通過memcpy函式將髒頁先拷貝到記憶體中的doublewrite buffer，之後通過doublewrite buffer再分兩次，每次寫入1MB到共享表空間的物理磁碟上，然後馬上呼叫fsync函式，同步磁碟，避免緩衝寫帶來的問題。在這個過程中，因為doublewrite頁是連續的，因此這個過程是順序寫的，開銷並不是很大。在完成doublewrite頁的寫入後，再將doublewrite buffer中的頁寫入各個表空間檔案中，此時的寫入則是離散的。

可以通過以下命令觀察到doublewrite執行的情況： show global status like 'innodb_dblwr%'\G

doublewrite一共寫了18 445個頁，但實際的寫入次數為434，(42:1)   基本上符合64:1。

如果發現你的系統在高峰時Innodb_dblwr_pages_written:Innodb_dblwr_writes遠小於64:1，那麼說明你的系統寫入壓力並不是很高。

如果作業系統在將頁寫入磁碟的過程中崩潰了，在恢復過程中，InnoDB儲存引擎可以從共享表空間中的doublewrite中找到改頁的一個副本，將其拷貝到表空間檔案，再應用重做日誌。下面顯示了由doublewrite進行恢復的一種情況： 

引數skip_innodb_doublewrite可以禁止使用兩次寫功能，這時可能會發生前面提及的寫失效問題。不過，如果你有多臺從伺服器（slave server），需要提供較快的效能（如slave上做的是RAID0），也許啟用這個引數是一個辦法。不過，在需要提供資料高可靠性的主伺服器（master server）上，任何時候我們都應確保開啟兩次寫功能。

注意：有些檔案系統本身就提供了部分寫失效的防範機制，如ZFS檔案系統。在這種情況下，我們就不要啟用doublewrite了。 

自適應雜湊索引

雜湊（hash）是一種非常快的查詢方法，一般情況下查詢的時間複雜度為O(1)。常用於連線（join）操作，如SQL Server和Oracle中的雜湊連線（hash join）。但是SQL Server和Oracle等常見的資料庫並不支援雜湊索引（hash index）。MySQL的Heap儲存引擎預設的索引型別為雜湊，而InnoDB儲存引擎提出了另一種實現方法，自適應雜湊索引（adaptive hash index）。

InnoDB儲存引擎會監控對表上索引的查詢，如果觀察到建立雜湊索引可以帶來速度的提升，則建立雜湊索引，所以稱之為自適應（adaptive）的。自適應雜湊索引通過緩衝池的B+樹構造而來，因此建立的速度很快。而且不需要將整個表都建雜湊索引，InnoDB儲存引擎會自動根據訪問的頻率和模式來為某些頁建立雜湊索引。

根據InnoDB的官方文件顯示，啟用自適應雜湊索引後，讀取和寫入速度可以提高2倍；對於輔助索引的連線操作，效能可以提高5倍。自適應雜湊索引是非常好的優化模式，其設計思想是資料庫自優化（self-tuning），即無需DBA對資料庫進行調整。

檢視當前自適應雜湊索引的使用狀況：show engine innodb status\G

現在可以看到自適應雜湊索引的使用資訊了，包括自適應雜湊索引的大小、使用情況、每秒使用自適應雜湊索引搜尋的情況。值得注意的是，雜湊索引只能用來搜尋等值的查詢，如select * from table where index_col='xxx'，而對於其他查詢型別，如範圍查詢，是不能使用的。因此，這裡出現了non-hash searches/s的情況。用hash searches:non-hash searches命令可以大概瞭解使用雜湊索引後的效率。

由於自適應雜湊索引是由InnoDB儲存引擎控制的，所以這裡的資訊只供我們參考。不過我們可以通過引數innodb_adaptive_hash_index來禁用或啟動此特性，預設為開啟。