1. InnoDB AHI的作用 InnoDB的適應哈希(AHI)是維護InnoDB葉子頁記錄的索引鍵值(或鍵值前綴)的到葉子節點記錄的Hash映射關系。能夠根據索引鍵值(或前綴)定位到記錄的地址。這樣可以不用再搜索B+樹從root到葉子頁的路徑定位過程。
2. InnoDB AHI的維護 為了避免頻繁的更新AHI帶來性能的開銷，InnoDB的AHI不是隨時可以更新的。 首先要滿足 index->search_info->hash_analysis >= BTR_SEARCH_HASH_ANALYSIS(17)，即在這個索引上至少進行了17此查詢(指通過B+樹的路徑查詢，不包含通過AHI查找)才進行一次是否需要建hash的分析。 分析是否需要建索引: buf_block_struct->n_hash_helps?用相同的前綴(n_fields,n_bytes,left_side)進行的查詢 成功的次數(btr_search_update_block_hash_info). ?如果次數大于該頁記錄總數的1/16時,就有可能在該頁上建立AHI.? 并且index->search_info->n_hash_potential >= BTR_SEARCH_BUILD_LIMIT(100)，即表示查詢已經連續成功使用Hash Index(btr_search_guess_on_hash), 或者是可能成功使用Hash Index的次數(btr_search_info_update_hash) 大于100. 原來沒有創建hash，或者原來創建hash的前綴參數發生了改變(n_fields, n_bytes, left_side)，則需要重新對這個頁上的記錄創建AHI.
索引的創建： 如果需要創建新的AHI，如果原來在這頁上已經建立和哈希索引，則需要先刪除原來的這頁上的AHI。建立新的AHI，從這頁的第一個記錄開始，到最后的一個記錄，依次根據前綴的參數(n_fields,n_bytes,left_side)計算hash的key，然后插入哈希表中。
插入記錄時添加哈希記錄: 當一頁插入一條記錄時，如果這頁已經被創建哈希，則將這個新記錄也插入哈希表。函數: btr_search_update_hash_node_on_insert(); btr_search_update_hash_on_insert()。

3.?InnoDB?AHI前綴參數的確定: hash前綴參數(n_fields, n_bytes, left_side)的確定需要根據這次查詢的結果來確定，即查詢結束后btr_cur_t結構中的參數來確定；主要是比較cursor->up_match, cursor->up_bytes, cursor->low_match, cursor->low_bytes，即查詢結束后查詢游標指向的前后記錄的匹配程度來確定前綴的參數。 以匹配少的記錄作為前綴，即cursor->up_match，cursor->up_bytes組合與cursor->low_match, cursor->low_bytes比較結果，如果前者大則用后者來更新info->n_fields和info->n_bytes，此時info->left_side = TRUE，即當遇到相同記錄前綴時,是選擇最左邊插入hash表，后者大則用前者來更新info->n_fields和info->n_bytes，此時info->left_side = FALSE，當遇到相同記錄前綴時,是選擇最右邊的記錄插入hash表，即相同的前綴只用保留一個記錄在hash表中。 如果分析過程中發現查詢的結果和上次得到的結果不同，則需要重新前綴參數(n_fields, n_bytes, left_side)。
4. InnoDB AHI使用 在btr_cur_search_to_nth_level中，在使用B+Tree搜索前，先搜索AHI(btr_search_guess_on_hash)，看是否可以找到相應的記錄。查找到記錄后還需要檢查找到的記錄是否符合要求(btr_search_check_guess)，即根據Search Path(PAGE_CUR_G, PAGE_CUR_GE, PAGE_CUR_L, PAGE_CUR_LE)與tuple和當前記錄的比較結果btr_cur_t結構中的參數來判斷。如果符合要求則返回相應的記錄，否則還是采用B+Tree來查詢。

總結

以上是生活随笔為你收集整理的InnoDB Adaptive Hash Index(AHI)的全部內容，希望文章能夠幫你解決所遇到的問題。

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