作者：周信靜，畢業于浙江大學，目前在CDB/CynosDB數據庫內核團隊參與TXSQL云數據庫內核研發工作，參與了熱點行更新以及一系列性能優化工作，并修復了多個MySQL官方bug。

1背景

InnoDB的自適應哈希索引（Adpative Hash Index，以下簡稱AHI），是一種建立在B樹索引結構上的索引結構，目的是為了進一步降低BTree的查詢代價。

在B樹中搜索一個記錄時，需要從根節點下降到葉子結點，同時在每個節點中還需要使用二分查找定位。而AHI對此的改進在于它對BTree索引頻繁訪問的葉子的行記錄建立哈希索引，這樣在執行B樹查詢時，通過AHI就可能能定位到葉子結點上的記錄位置，避免B樹根節點到葉子結點的下降過程，減少了CPU開銷。

由于AHI的構建是一個自適應且動態的過程，需要根據查詢負載訪問模式的變更、頁面的換入和淘汰等情況做AHI對應清理或者重建，所以本質上來說AHI也是一個cache，具體的構建邏輯網絡上也有很多文章講解，不是本文討論的重點。

本文要討論的是一個鮮為人知的AHI構建鎖沖突問題以及相應優化。

2問題

TXSQL 5.7版本在跑sysbench時，我們觀察到一個非常有意思的現象。

實驗環境是這樣的，2臺96-core的機器，分別作為sysbench client和mysql server，我們配置buffer pool大小為200GB，同時生成一張120GB的sysbench table。

如下圖所示，我們執行128并發的oltp_read_only負載時，觀察到QPS首先有一個上升的坡，這段時間我們發現系統有大量的讀IO，正在填充buffer pool，屬于正常狀態。

然后過了100s時突然出現了一個急劇的下降，在400s后開始系統QPS開始緩慢上升，直到800s后達到峰值。

通過perf工具抓取系統在QPS劇降時間點的狀態，結果如下圖：

分析堆棧，可以發現，大量CPU花費在在AHI的hash table的鎖競爭上。

仔細分析不難發現，這個時候大多數頁面基本上還沒有建立AHI，然后多個線程同時需要對頁面建立AHI索引，而這個構建過程需要對同一個AHI hash table加X鎖，因此造成了大量等待。

從QPS變化的角度，可以有如下圖所示的分析：

3優化

我們注意到，對于一個BTree索引來說，其AHI構建是在BTree葉子結點定位完畢后發生的，對應調用鏈如下：

btr_cur_search_to_nth_level→?btr_search_info_update→?btr_search_info_update_slow→?btr_search_build_page_hash_index

在btr_search_info_update_slow中，根據統計信息作出決定，調用btr_search_build_page_hash_index把當前頁面的記錄加入AHI的hash table，這個過程需要獨占hash table的X鎖。

既然只能有一個線程對hash table進行修改，那么其他并發構建AHI線程等待這個hash table的X鎖是相當不明智的，因為這樣block住了查詢的關鍵路徑，同時只有一個線程在做這個構建工作。

同時我們又注意到AHI只是一個輔助cache，其實用BTree也是能夠正確處理查詢的。

那么很自然的，我們可以想到如下的優化方式：

1. 當我們在BTree查詢路徑上經過分析后決定要對某一頁構建AHI索引時，我們首先看一下該BTree所對應的hash table的鎖是否被其他線程拿住了寫鎖；

2. 如果被拿住了寫鎖，我們取消這次針對頁的AHI索引構建任務，等待下次再次訪問到該頁時再嘗試去構建，fallback到普通的BTree查詢。

4具體實現

從實現角度來說，其實非常簡單：在btr_search_info_update_slow根據統計信息判斷要對一頁的記錄建立AHI索引時，我們加入一個條件判斷：如果當前有并發AHI構建線程拿住了hash table的X鎖，我們直接返回即可。

代碼只有幾行，大致如下：

有人可能會擔心這樣直接跳過會不會影響代碼正確性？

答案是否定的，因為我們這里沒有清除該頁面關于AHI的任何統計信息，只是推遲了構建時機，即推遲到hash table鎖沖突不嚴重的時候再進行。

5效果

應用上述的優化后，我們重新執行上述實驗，得到如下的結果圖：

其中，紅線（開啟AHI+Contention Avoidance優化）是我們實現上述優化后結果，經過100s左右的預熱后，性能穩定，鎖瓶頸消失。

6靈感來源

其實在原始的AHI查詢路徑上已經有一個類似的優化了：

在btr_cur_search_to_nth_level中執行AHI查詢前，如果發現AHI的hash table被其他線程X鎖住了，直接fallback到BTree查詢。

這里的優化考量是類似的：與其等待AHI的hash table的X鎖，不如直接走btree搜索，代價很可能比等待X鎖更低，并發度更高。

7總結

該優化目前已經在TXSQL5.7最新版本中上線，將會有效緩解AHI構建的鎖競爭問題，可能的場景包括不限于：系統啟動、AHI開關剛開啟、主備切換時，所有頁面都還沒有AHI記錄，高并發可能導致大量的AHI構建工作。

同時經過我們驗證，在官方MySQL的5.7和8.0最新版本中都存在該問題，因此我們也已經將這個優化思路貢獻給了官方, https://bugs.mysql.com/bug.php?id=100512 ，目前正在評估，相信不久將合入主線。

手機運維小程序限時免費體驗！

手機運維小程序——騰訊云數據庫上線啦，從此在手機里可以實現實例信息查看，健康報告接收，慢SQL分析和異常查看等功能，以后回家終于可以不背電腦了！

上云就上騰訊云，雙十一全網年度最低價來襲：MySQL高可用版1C2G低至99元/年！更有價值11000元代金券大禮包等你來領取，玩法簡單直接，錯過又要等一年！

↓↓點擊直達雙11會場~?

【騰訊程序員視頻號交流沙龍活動預告】

11月21日周六下午2點?深圳

想參與可添加微信：journeylife1900

（備注：視頻號）

總結

以上是生活随笔為你收集整理的一个即将写入MySQL源码的官方bug解决之路的全部內容，希望文章能夠幫你解決所遇到的問題。

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