目前，美團內部的日均慢查詢數量已經超過上億條，如何對對這些慢查詢進行分析並建立合適的索引，是美團數據庫研發中心面臨的一項挑戰。美團數據庫平臺研發組與華東師範大學展開了科研合作，通過基於AI+數據驅動的索引推薦，來與基於代價的方法並行地爲慢查詢推薦索引，以提升推薦效果。
1 背景
隨着美團業務量的不斷增長，慢查詢的數量也日益增多。目前，日均慢查詢數量已經超過上億條，如果僅依靠DBA和開發人員手動地對這些慢查詢進行分析並建立合適的索引，顯然是不太現實的。爲了解決這一難題，美團內部DAS（數據庫自治服務）平臺已經集成了基於代價的慢查詢優化建議來自動地爲慢查詢推薦索引。然而，仍然存在一些問題：
- 基於代價的慢查詢優化建議是藉助於優化器的代價估計，來推薦出對於查詢代價改善最大的索引，但優化器的代價估計並不是完全準確[1]，因此可能存在着漏選或者錯選推薦索引的問題。
- 基於代價的慢查詢優化建議需要計算查詢在不同索引下查詢代價的改善程度，因此需要進行大量的增刪索引操作，但真實增刪索引的代價是非常大的，需要藉助於假索引[2]技術，假索引技術並不創建真實的物理索引文件，只是通過模擬索引存在時的查詢計劃來估算索引對於查詢的收益。目前，美團大部分業務都是運行在MySQL實例上的，不同於商業數據庫SQL Server和開源數據庫PostgreSQL，MySQL內部並沒有集成假索引技術，因此需要自己構建支持假索引的存儲引擎，其開發成本較高，這也是目前DAS平臺基於代價的慢查詢優化建議所採用的方案。
爲了解決上述兩個問題，美團數據庫研發中心與華東師範大學數據科學與工程學院展開了《基於數據驅動的索引推薦》的科研合作，雙方通過在DAS平臺上集成基於AI+數據驅動的索引推薦，來與基於代價的方法並行地爲慢查詢推薦索引，以提升推薦效果。
- 首先，基於代價的方法每天會爲慢查詢推薦索引，並在採樣庫上評估推薦的索引是否真正地改善了查詢的執行時間，這爲AI方法積累了大量可信的訓練數據，根據此數據訓練的AI模型，可以在一定程度上彌補基於代價的方法漏選或錯選索引的問題。
- 其次，基於AI的方法將針對慢查詢的索引推薦看作是二分類問題，通過分類模型直接判別在某一列或某些列上建立索引是否能夠改善查詢的執行性能，並不藉助於查詢優化器和假索引技術，這使得AI方法更加通用，且開發成本更低。
2 索引推薦介紹
索引推薦可以劃分爲兩個級別：Workload級別和Query級別：
- 在Workload級別，索引推薦是在限制的索引存儲空間或索引個數下，推薦出一組最優的索引集合來使得整個Workload的代價最低。
- Query級別的索引推薦可以被視爲Workload級別索引推薦的簡化版本，在Query級別，索引推薦是爲單個慢查詢推薦缺失的索引，以改善其性能。
2.1 基於代價的索引推薦
基於代價的索引推薦[3]大多聚焦於Workload級別的索引推薦，出現在查詢中每一列或者列的組合都可以看作是一個能夠改善Workload代價的候選索引，所有的候選索引構成了一個巨大的搜索空間（候選索引集合）。
這是一個屬於NP-hard範疇的搜索問題<sup>[4]</sup>。目前，基於代價的索引推薦方法大多會採用“貪心策略”來簡化搜索過程，但這可能會導致最後推薦出的索引是次優解<sup>[5]</sup>。
2.2 基於AI+數據驅動的索引推薦
基於AI+數據驅動的索引推薦聚焦於Query級別的索引推薦，出發點是在某個數據庫中因爲缺失索引導致的慢查詢，在其它數據庫中可能有相似的索引創建案例：這些查詢語句相似，因此在相似位置上的列創建索引也可能帶來類似的收益。例如下圖中，查詢$q_s$和$q_t$在語句結構和列類型上非常相似。因此，我們可以通過學習查詢$q_s$的索引創建模式來爲查詢 $q_t$推薦缺失的索引。
對於不同列數的索引推薦，我們會分別訓練基於XGBoost的二分類模型。例如，我們目前最高支持三列的索引推薦，因此會分別訓練一個單列索引推薦模型、一個兩列索引推薦模型和一個三列索引推薦模型。對於給定的一個單列候選索引和它對應的慢查詢，我們使用單列索引推薦模型來判斷該單列候選索引是否能夠改善該慢查詢的性能。
同樣的，對於給定的一個兩列（三列）候選索引和它對應的慢查詢，我們使用兩列（三列）索引推薦模型來判斷這個兩列（三列）候選索引是否能夠改善該慢查詢的性能。如果一條慢查詢中包含的候選索引個數爲$N$，那麼則需要$N$次模型預測來完成對這條慢查詢的索引推薦。
3 整體架構
基於AI+數據驅動的索引推薦的整體架構如下圖所示，主要分爲兩個部分：模型訓練和模型部署。
3.1 模型訓練
如上文所述，我們收集DAS平臺基於代價的慢查詢優化建議每天的索引推薦數據（包括慢查詢和被驗證有效的推薦索引）作爲訓練數據。我們生成每條查詢的單列、兩列和三列候選索引，並通過特徵工程來爲每個候選索引構建特徵向量，使用索引數據來爲特徵向量打標籤。之後，單列、兩列和三列特徵向量將分別用於訓練單列、兩列和三列索引推薦模型。
3.2 模型部署
針對需要推薦索引的慢查詢，我們同樣生成候選索引並構建特徵向量。接下來，我們使用分類模型來預測特徵向量的標籤，即預測出候選索引中的有效索引。隨後，我們在採樣庫上創建模型預測出的有效索引，並通過實際執行查詢來觀察建立索引前後查詢性能是否得到改善。只有當查詢性能真正得到改善時，我們纔會將索引推薦給用戶。
4 建模過程
4.1 生成候選索引
我們提取查詢中出現在聚合函數、WHERE、JOIN、ORDER BY、GROUP BY這些關鍵詞中的列作爲單列候選索引，並對這些單列候選索引進行排列組合來生成兩列和三列候選索引。同時，我們會獲取查詢所涉及的表中已經存在的索引，並將其從候選索引集合中刪除。這一步驟遵循索引的最左前綴原則：如果存在索引$Idx (col1, col2)$，那麼候選索引 $(col1)$ 和 $(col1, col2)$ 都將從候選索引集合中刪除。
4.2 特徵工程
一個候選索引的特徵向量包括語句特徵和統計特徵兩部分。語句特徵描述了候選索引列在查詢中的出現位置（採用one-hot的編碼方式），統計特徵描述了候選索引列的統計信息，如所在表的錶行數、Cardinality值、選擇率等，這些是判斷是否需要在候選索引列上建立索引的重要指標。
下表以單列候選索引 $(col1)$ 爲例，展示了它的部分重要特徵及其含義：
兩列候選索引 $(col1, col2)$ 的特徵是通過對單列候選索引 $(col1)$ 和 $(col2)$ 的特徵進行拼接而成的，此外，我們還會計算 $col1$ 和 $col2$ 共同的Cardinality值作爲兩列候選索引 $(col1, col2)$ 的額外統計特徵，以更加全面地描述其統計信息。同樣地，我們也會採用使用這種方式來構建三列候選索引 $(col1, col2, col3)$ 的特徵。在生成完一條查詢的特徵向量之後，我們使用這條查詢使用到的索引來爲生成的特徵向量打標籤。
4.3 建模舉例
下圖以查詢 $q_1$ 爲例，展示我們爲訓練集中的一條查詢生成特徵向量並打標籤的過程。查詢 $q_1$ 涉及兩張表customer表和warehouse表，其中customer表的c_w_id、c_id、c_d_id、c_last四列參與到查詢中，因此對應生成四條單列特徵向量；warehouse表的w_id列參與到查詢中，因此只生成了一條單列特徵向量。查詢 $q_1$ 使用的單列索引爲Idx(w_id)，所以單列候選索引 (w_id) 對應的特徵向量被標記爲正樣本，其餘特徵向量則被標記爲負樣本。
接下來，我們對單列候選索引進行排列組合來生成多列候選索引及其特徵向量。由於查詢 $q_1$ 使用到的多列索引只有一個三列索引Idx(c_d_id, c_id, c_last)，因此我們跳過生成兩列候選索引，只生成三列候選索引。這是因爲我們是基於查詢使用到的索引來爲特徵向量打標籤的，如果查詢沒有使用到兩列索引，那麼生成的所有兩列特徵向量均爲負樣本，這可能會導致訓練集正負樣本不均衡的問題。
最後，基於查詢使用到的三列索引，我們將三列候選索引 (c_d_id, c_id, c_last) 對應的特徵向量標記爲正樣本。以上就是我們爲查詢 $q_1$ 生成特徵向量並打標籤的整個過程，查詢 $q_1$ 爲單列索引推薦模型的訓練集貢獻了五條樣本（一條正樣本，四條負樣本），爲三列索引推薦模型的訓練集貢獻了六條樣本（一條正樣本，五條負樣本）。
4.4 模型預測和索引評估
在爲一條慢查詢推薦索引時，我們依次生成慢查詢中所有的單列、雙列和三列候選索引，並通過上述的特徵工程來構造特徵向量。然後，我們將特徵向量輸入給對應的分類模型進行預測，並從三個分類模型的預測結果中分別挑選出一個預測概率最高的候選索引（即一個單列索引、一個兩列索引和一個三列索引）作爲模型推薦的索引。
雖然推薦的索引越多，慢查詢的性能就越有可能得到改善，但是模型推薦的部分索引可能是無效的，這些無效索引帶來的存儲空間開銷和更新索引的開銷是不可忽視的。因此，直接將模型推薦的索引全部推薦給用戶是不合理的。爲此，在將索引推薦給用戶之前，我們會首先將三個分類模型推薦的索引建立在採樣庫上進行驗證，採樣庫是線上數據庫的一個mini版本，它抽取了線上數據庫的部分數據。在採樣庫上，我們會觀察在建立推薦的索引之後，查詢的執行時間是否得到改善。如果得到改善，我們就把查詢使用到的一個或多個模型推薦的索引作爲索引建議推薦給用戶。
5 項目運行情況
正如前文所述，美團DAS平臺目前採用代價方法和AI模型並行爲慢查詢推薦索引。具體來說，AI模型可以在某些場景下，彌補代價方法漏選或錯選推薦索引的問題。就在剛過去的3月份，在代價方法推薦索引的基礎上，AI模型有額外12.16%的推薦索引被用戶所採納。
這些額外補充的索引對於查詢的改善情況如上圖所示：上半部分展示了優化的查詢執行次數，下半部分展示了查詢在使用推薦的索引之後的執行時間以及減少的執行時間，這些索引總計約優化了52億次的查詢執行，減少了4632小時的執行時間。
6 未來規劃
目前，大模型技術（如GPT-4）已經得到了越來越多的認可，幾乎可以勝任各種領域的任務。我們計劃嘗試通過Fine-Tune開源的大型語言模型（如Google開源的T5模型）來解決索引推薦的問題：輸入一條慢查詢，讓模型來生成針對慢查詢的索引建議。
在推薦索引無法改善慢查詢的情況下，後續我們可以提供一些文本建議來幫助用戶優化SQL，比如減少返回不必要的列，使用JOIN代替子查詢等。
7 本文作者
彭淦，美團基礎研發平臺工程師，主要負責美團數據庫自治服務DAS的SQL優化建議工作。
8 特別感謝
在這裏特別感謝華東師範大學數據科學與工程學院的蔡鵬教授，教授在VLDB、ICDE、SIGIR、ACL等領域重要國際會議上發表多篇論文。目前的研究方向爲內存事務處理，以及基於機器學習技術的自適應數據管理系統。本文也是美團數據庫研發中心跟蔡鵬教授展開科研合作後的具體實踐。
9 參考文獻
- [1] Leis V, Gubichev A, Mirchev A, et al. 2015. How good are query optimizers, really? Proc. VLDB Endow. 9, 3 (2015), 204-215.
- [2] https://github.com/HypoPG/hypopg
- [3] Kossmann J, Halfpap S, Jankrift M, et al. 2020. Magic mirror in my hand, which is the best in the land? an experimental evaluation of index selection algorithms. Proc. VLDB Endow. 13,12 (2020), 2382-2395.
- [4] Piatetsky-Shapiro G. 1983. The optimal selection of secondary indices is NP-complete. SIGMOD Record. 13,2 (1983), 72-75.
- [5] Zhou X, Liu L, Li W, et al. 2022. Autoindex: An incremental index management system for dynamic workloads. In ICDE. 2196-2208.
閱讀更多
| 在美團公衆號菜單欄對話框回覆【2022年貨】、【2021年貨】、【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可查看美團技術團隊歷年技術文章合集。
