1.前言

　　雜湊是一種非常快的查詢方法，在一般情況下這種查詢的時間複雜度為O(1)，即一般僅需要一次查詢就能定位資料，而B+樹的查詢次數，取決於B+樹的高度，在生產環境中，B+樹的高度一般為3~4層，故需要3~4次查詢。

2.Adaptive Hash index(AHI)

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

3.自適應雜湊索引要求

　　AHI有一個要求，即對這個頁的連續訪問模式必須是一樣的，例如(a,b)的聯合索引頁，其訪問模式可以是以下情況

• where a=xxx
• where a=xxx and b=xxx

訪問模式一樣指的是查詢條件一樣，若交替進行上述兩種查詢，那麼innodb儲存引擎不會對該頁構造AHI，此外AHI還有如下的要求：

• 以該模式訪問了100次
• 頁通過該模式訪問了N次，其中N=頁中記錄 * 1/16

根據innodb儲存引擎官方的文件顯示，啟動了AHI之後，讀取和寫入速度可以提升2倍，輔助索引的連線操作效能可以提升5倍。毫無疑問，AHI是非常好的優化模式，設計的思想是資料庫自優化的(self-tuning)，即無需要DBA對資料庫進行人為調整。

　　我們可以通過show engine innodb status命令檢視當前AHI的使用情況：　　

Hash table size 34673, node heap has 0 buffer(s)
Hash table size 34673, node heap has 0 buffer(s)
Hash table size 34673, node heap has 0 buffer(s)
Hash table size 34673, node heap has 0 buffer(s)
Hash table size 34673, node heap has 0 buffer(s)
Hash table
 
 size 34673, node heap has 0 buffer(s)
Hash table size 34673, node heap has 0 buffer(s)
Hash table size 34673, node heap has 0 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s            ##這裡表示的使用雜湊索引的次數和未使用雜湊索引的次數

4.雜湊索引的缺陷　

• 索引存放的是hash值,所以僅支援 < = > 以及 IN 操作
• hash索引無法通過操作索引來排序，因為存放的時候經過hash計算，但是計算的hash值和存放的不一定相等，所以無法排序
• 不能避免全表掃描，只是由於在memory表裡支援非唯一值hash索引，就是不同的索引鍵，可能存在相同的hash值
• 如果雜湊碰撞很多的話，效能也會變得很差
• 雜湊索引無法被用來避免資料的排序操作

參考：http://mysql.taobao.org/monthly/2015/09/01/

　　　https://zhuanlan.zhihu.com/p/268341368

　　　http://blog.itpub.net/15498/viewspace-2157462/

　　 https://blog.csdn.net/cpongo6/article/details/88793524