功能特性

在MySQL中，對雜湊索引的訪問僅需要一次HASH計算即可定位到目標位置，而對B樹索引的訪問需要依次訪問根節點>中間節點>葉子節點。 為優化B樹索引需要訪問多個"非葉子節點頁"才能定位到"葉子節點頁"的問題，InnoDB儲存引擎通過雜湊索引來幫助查詢快速找到"目標葉子節點頁"以提高查詢效能。 InnoDB儲存引擎通過監控表上索引頁的查詢模式，自動根據查詢模式對"熱點資料"來建立雜湊索引，因此被成為自適應雜湊索引。 自適應雜湊索引使用Buffer pool中的資料頁進行構造，僅儲存在記憶體中，不會持久化到磁碟上，且僅對熱點資料進行處理，因此構造自適應雜湊索引速度極快。 自適應雜湊索引不會對同一資料頁中所有記錄進行索引，而是根據訪問模式決定對相同鍵值的記錄進行如何索引，如對"大於等於"和"小於等於"兩種模式採用不同方式。 InnoDB儲存引擎僅支援B樹索引，不支援雜湊索引和全文索引。 可以通過SHOW ENGINE INNODB STATUS命令來檢視當前例項上自適應雜湊索引的使用情況，如

-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
 
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 796967, node heap has 0 buffer(s)
Hash table size 796967, node heap has 0 buffer(s)
Hash table size 
 
796967, node heap has 343 buffer(s)
Hash table size 796967, node heap has 0 buffer(s)
Hash table size 796967, node heap has 0 buffer(s)
Hash table size 796967, node heap has 2 buffer(s)
Hash table size 796967, node heap has 1 buffer(s)
Hash table size 796967, node heap has 3 buffer(s)
0.00 hash searches/s, 0.00
 
 non-hash searches/s

PS1: SHOW ENGINE INNODB STATUS命令用來展示儲存引擎一段時間的狀態資料，而非當前資料。

PS2: hash searches和non-hash searches可能不準，在相同訪問頻率下，其值從幾十暴漲至幾十萬。

支援操作

自適應雜湊索引是針對B+樹索引的查詢模式來優化，其支援的操作型別有： 1、唯一查詢(Unique Scan) 2、範圍查詢(Range Scan locat first key page) 3、增刪改(INSERT/DELETE/UPDATE)

使用條件

1、使用索引訪問17次(BTR_SEARCH_HASH_ANALYSIS) 2、使用相同查詢模式訪問100次(BTR_SEARCH_BUILD_LIMIT) 3、資料頁被相同模式訪問N次(N=頁中記錄*1/16)

功能優點

根據InnoDB儲存引擎官方的文件顯示，啟用AHI後： 1、讀取和寫入速度可以提高2倍 2、輔助索引的連線操作效能可以提高5倍

功能缺點

1、對熱點資料頁構造自適應雜湊索引需要相同模式連續執行，使用不同訪問模式交替執行不會觸發，無法控制業務訪問順序。 2、自適應雜湊索引在DML操作引發的資料變化時處理效率成本較高，需要根據不同型別操作對雜湊索引進行維護。 3、自適應雜湊索引在維護雜湊索引時使用全域性latch物件來限制併發，可能影響到業務併發效能。 4、自適應雜湊索引使用快取池記憶體來存放雜湊索引資料，可能會記憶體佔用過多導致快取池資料命中率降低和磁碟讀操作增加。

功能缺陷

在使用自適應雜湊索引時應關注其鎖爭用情況，極端情況下會導致資料庫異常宕機。 You can monitor the use of the adaptive hash index and the contention for its use in the SEMAPHORES section of the output of the SHOW ENGINE INNODB STATUS command. If you see many threads waiting on an RW-latch created in btr0sea.c, then it might be useful to disable adaptive hash indexing. Sometimes, the read/write lock that guards access to the adaptive hash index can become a source of contention under heavy workloads, such as multiple concurrent joins.

參考資料

https://blog.51cto.com/hcymysql/1347504