做者 周信靜，畢業於浙江大學，目前在CDB/CynosDB數據庫內核團隊參與TXSQL雲數據庫內核研發工做，參與了熱點行更新以及一系列性能優化工做，並修復了多個MySQL官方bug。php
Part1 背景
InnoDB的自適應哈希索引（Adpative Hash Index，如下簡稱AHI），是一種創建在B樹索引結構上的索引結構，目的是爲了進一步下降BTree的查詢代價。mysql
在B樹中搜索一個記錄時，須要從根節點降低到葉子結點，同時在每一個節點中還須要使用二分查找定位。而AHI對此的改進在於它對BTree索引頻繁訪問的葉子的行記錄創建哈希索引，這樣在執行B樹查詢時，經過AHI就可能能定位到葉子結點上的記錄位置，避免B樹根節點到葉子結點的降低過程，減小了CPU開銷。sql
因爲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 發佈