一個即將寫入MySQL原始碼的官方bug解決之路

作者：周信靜，畢業於浙江大學，目前在CDB/CynosDB資料庫核心團隊參與TXSQL雲資料庫核心研發工作，參與了熱點行更新以及一系列效能最佳化工作，並修復了多個MySQL官方bug。

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

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

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

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

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

我們注意到，對於一個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查詢。

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

程式碼只有幾行，大致如下：

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

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

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

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

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

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

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

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

同時經過我們驗證，在官方MySQL的5.7和8.0最新版本中都存在該問題，因此我們也已經將這個最佳化思路貢獻給了官方, ，目前正在評估，相信不久將合入主線。

一個即將寫入MySQL原始碼的官方bug解決之路

相關文章