說起AHI(Adaptive Hash Index)，有的同學估計很陌生，都沒聽說，沒關系，下面我會詳細解釋說明的，AHI是什么，mysql庫為什么要設計AHI，解決什么問題，只有了解這些原理之后，才能判斷，你的業務庫是否需要AHI。

在說AHI之前，先給大家提一下B+tree索引層數的問題，我們都是知道，隨著MySQL數據庫單表數據量越來越多(在這里留一個問題，多少數據量，才會導致B+tree層數增加呢？)，B+tree的層數會逐漸增高。

當數據層數增加，索引檢索時，從根節點到葉子節點的時間成本就會變大，這是因為需要搜索更多的枝節點。

這個時候，Mysql數據庫的設計者，就考慮用一種技術去解決檢索成本的問題，使用一種緩存結構，使用檢索條件，可以直接查詢需要的葉子節點數據，而不用逐層的搜索，跳過枝節點。這個緩存結構就是AHI，也就是自適應哈希索引(Adaptive Hash Index)。

在mysql數據庫中AHI默認是開啟的，并且占用buffer pool大小的1/16

[root@localhost] 14:11:04 [(none)]>show variables like '%innodb_adaptive_hash_index%';+----------------------------------+-------+| Variable_name | Value |+----------------------------------+-------+| innodb_adaptive_hash_index | ON || innodb_adaptive_hash_index_parts | 8 |+----------------------------------+-------+2 rows in set (0.00 sec)

AHI是可以在線關閉的，執行以下命令就可以關閉了

[root@localhost] 14:16:47 [(none)]>set global innodb_adaptive_hash_index=off;Query OK, 0 rows affected (0.00 sec)[root@localhost] 14:16:57 [(none)]>show variables like '%innodb_adaptive_hash_index%';+----------------------------------+-------+| Variable_name | Value |+----------------------------------+-------+| innodb_adaptive_hash_index | OFF || innodb_adaptive_hash_index_parts | 8 |+----------------------------------+-------+2 rows in set (0.00 sec)

而且不是B+tree索引樹上什么數據都能進入到AHI的，是需要滿足一定條件才能被加載到AHI緩沖區

寫到這里，大家可能有點迷糊了，既然AHI是為了提高索引查詢效率，減少搜索時間的，為什么要關閉呢？

在這里大家回想一下，AHI解決的是什么問題，是因為B+tree索引層數高，導致索引搜索時間變成，那么這里就得想想，B+tree索引層數到底有多高，多少業務記錄數才會到知道層數加1。

在MySQL中一個頁大小為16Kb，這個是可以從參數里查看的

[root@localhost] 15:59:19 [(none)]>show variables like 'innodb_page_size';+------------------+-------+| Variable_name | Value |+------------------+-------+| innodb_page_size | 16384 |+------------------+-------+1 row in set (0.00 sec)

如果業務表一條記錄平均長度為1Kb，那么1個頁，可以存放16條業務記錄，假設主鍵ID為bigint類型，其長度為8個字節，在B+tree里，頁面指針大小為6字節，這樣枝節點和根節點，一條記錄是14字節，那么一個頁中能存放多少這樣的記錄呢，16384/14=1170，一顆高度為2的B+tree可以存放1170 * 16=18720條記錄，如果高度為3，則可以存放1170 * 1170 * 16=21902400條記錄，大約2000多萬條記錄，可以滿足絕大多數單表記錄條數了，如果是交易訂單表超過，建議分表，保證單表記錄數不超過500W，單表大小不超過10G。

上述例子講的是主鍵索引，普通的二級索引的情況呢，假設主鍵ID為bigint類型，其長度為8個字節，二級索引為vachar類型，長度為10，那么索引葉子節點可以存放16384/48=341，在這里需要注意如果是utf8，則占用30字節，utf8mb4則占用40字節，假設二級索引10個長度全部寫滿，在utf8mb4情況下，頁面指針大小6字節+二級索引列長度40，一個16k的非葉子節點頁能存放16384/46=356條記錄。
一顆高度為2的B+tree能存放的索引記錄為：341 * 356 = 121396
一顆高度為3的B+tree能存放的索引記錄為：341 * 356 * 356 = 43216976
可以看到大約能存放4000多萬二級索引數據。

綜上可以看出，生產上的B+tree的高度基本不會超過3，而能被加載到AHI緩沖區的數據也不會太多，除非是經常被索引查詢的業務數據，而且現在數據庫服務器開始大量使用SSD盤，隨機讀的速度也很快，可以考慮關閉AHI，將內存釋放，還給buffer pool，同時，在做truncate table，drop table時，不用再清理AHI中清理要刪除表的數據塊，提高truncate table，drop table速度。

總結

以上是生活随笔為你收集整理的mysql单表最大数据量_你的Mysql库真需要Adaptive Hash Index的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。