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

Part1 背景

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

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

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

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

Part2 問題

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變化的角度，可以有如下圖所示的分析：

Part3 優化

我們注意到，對于一個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也是能夠正確處理查詢的，

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

當我們在BTree查詢路徑上經過分析后決定要對某一頁構建AHI索引時，我們首先看一下該BTree所對應的hash table的鎖是否被其他執行緒拿住了寫鎖；
如果被拿住了寫鎖，我們取消這次針對頁的AHI索引構建任務，等待下次再次訪問到該頁時再嘗試去構建，fallback到普通的BTree查詢，

Part4 具體實作

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

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

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

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

Part5 效果

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

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

Part6 靈感來源

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

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

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

Part7 總結

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

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

本文由博客一文多發平臺 OpenWrite 發布！

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/222800.html

標籤：其它

上一篇：這是今天真正的大事：RCEP

下一篇：程式員雙十一剁手指南