作者：斯干，阿里雲資料庫高階技術專家

在我們業務系統中，資料庫越來越扮演著舉足輕重的角色。

和其它公司一樣，在阿里巴巴業務場景下，大部分業務跟資料庫有著非常緊密的關係，資料庫一個微小的抖動都有可能對業務造成非常大的影響，如何讓資料庫更穩定，得到持續最佳化一直都是非常重要的訴求。

資料庫環境下的業務最佳化，通常會提到三個層面：

1）應用層面最佳化：應用程式碼邏輯最佳化，以更高效的方式處理資料；

2）例項層面最佳化：透過環境引數調整，最佳化例項的執行效率；

3）SQL層面最佳化：透過物理資料庫設計、SQL語句改寫等最佳化手段，確保以最佳的方式獲取資料。

開發者通常對於前面兩個比較熟悉，對於第三個即SQL層面的最佳化會有些生疏，甚至會因由誰（資料庫管理員或應用開發者）來負責而產生爭論，但SQL最佳化是整個資料庫最佳化中非常關鍵的一環，線上SQL效能問題不僅會給業務帶來執行效率上的低下，甚至是穩定性上的故障。

按照經驗，約80%的資料庫效能問題能透過SQL最佳化手段解決，但SQL最佳化一直以來都是一個非常複雜的過程，需要多方面的資料庫領域專家知識和經驗。

例如如何準確地識別執行計劃中的瓶頸點，透過最佳化物理庫設計或SQL改寫等手段，讓資料庫最佳化器迴歸到最佳執行計劃，另外，由於SQL工作負載及其基礎資料龐大且不斷變化，SQL最佳化還是一項非常耗時繁重的任務，這些都決定了SQL最佳化是一項高門檻，高投入的工作。

SQL診斷最佳化服務是阿里雲資料庫自治服務（DAS）中最為核心的服務之一，它以SQL語句作為輸入，由DAS完成診斷分析並提供專家最佳化建議（包括索引建議、語句最佳化建議以及預期收益等資訊），使用者不必精通資料庫最佳化領域專家知識，即可獲得SQL最佳化診斷、改寫和最佳化相關的專家建議，最大化SQL執行效能。

另外，依託該能力，DAS的SQL自動最佳化服務將SQL最佳化推向了更高的境界，將重人工的被動式最佳化轉變為以智慧化為基礎的主動式最佳化，以自最佳化的自治能力實現SQL最佳化的無人值守。

接下來我們針對DAS的SQL診斷最佳化服務能力構建進行詳細的解讀。

01

面臨的挑戰

當我們提到診斷最佳化能力時，很自然會想到兩個問題：

能力是否靠譜？能力是否全面？

確實如此，完美地回答這兩個問題將面臨非常巨大的挑戰，現將其歸納為如下四點：

❓挑戰一：如何選擇靠譜的最佳化推薦演算法生成靠譜的建議？

在SQL診斷最佳化領域，基於規則方式和基於代價模型方式是兩種常被選擇的最佳化推薦演算法，在目前許多產品和服務中，基於規則的推薦方式被廣泛使用，特別是針對MySQL這種WHAT-IF核心能力缺失的資料庫，因為該方式相對來說比較簡單，容易實現，但另一面也造成了推薦過於機械化，推薦質量難以保證的問題，舉一個例子，例如對如下簡單的SQL進行索引的推薦:

SELECT *
FROM t1
WHERE time_created >= '2017-11-25'
AND consuming_time > 1000
ORDER BY consuming_time DESC

基於規則，通常會首先生成如下四個候選索引：

IX1(time_created)
IX2(time_created, consuming_time)
IX3(consuming_time)
IX4(consuming_time, time_created)

但最終推薦給使用者的是哪個（或哪幾個，考慮index oring/anding的情況）索引呢？基於規則的方式很難給出精確的回答，會出現模稜兩可的局面。在這個例子中，SQL只是簡單的單表查詢，那對於再複雜一點的SQL, 例如多個表Join,以及帶有複雜的子查詢，情況又會如何呢？情況變得更糟糕，更加難以為繼。

與此不同，DAS中的SQL診斷最佳化服務採用的是基於代價模型方式實現，也就它採用和資料庫最佳化器相同的方式去思考最佳化問題，最終會以執行代價的方式量化評估所有的（或儘可能所有的，因為是最優解求解的NP類問題，因此在一些極端情況下無法做到所有，只是實現次優）可能推薦候選項，最終作出推薦。即便是如此，但對於MySQL這樣的開源資料庫支援，還將面臨其它不一樣的挑戰：

WHAT-IF核心能力缺失：無法複用核心的資料庫最佳化器能力來對候選最佳化方案進行代價量化評估；
統計資訊缺失：候選最佳化方案的代價評估，其本質是執行計劃的代價計算，統計資訊的缺失便是無米之炊。

❓挑戰二：如何具備足夠的SQL相容性？

SQL診斷最佳化服務如何做到SQL相容性，其中包括SQL的解析以及SQL語義的驗證，這直接關係到能力的全面性，診斷的成功率，它就像入場券，做不到做不全面都是問題。

❓挑戰三：如何構建具有足夠覆蓋度的能力測試集？

長期以來，SQL診斷最佳化能力的構建一直都是頗具挑戰性的課題，挑戰不僅在於如何將據庫最佳化領域專家知識融入，還包括如何構建一個龐大的測試案例庫用於其核心能力驗證，它就像一把尺子可以衡量能力，同時又可以以此為驅動，加速能力的構建，因此在整個過程中，擁有足夠覆蓋度，準確的測試案例庫是能力構建過程中至關重要的一環。

但構建足夠好的測試案例庫是一件非常困難的事情，挑戰主要體現在兩個方面：

足夠完備性保證：影響SQL最佳化的因素很多，例如影響索引選擇的因素有上百個，加之各因素之間形成組合，這就形成了龐大的案例特徵集合，如何讓這些特徵一一對映到測試案例也是非常龐大的工程；
測試案例設計需要專業知識且資訊量大，例如對於單一測試案例設計也需要專業知識且測試案例中攜帶的資訊量大，如索引推薦測試案例，它包括：

a) schema設計：如表、已有索引、約束等；

b）各類統計資訊資料；

c）環境引數等等。

❓挑戰四：如何構建大規模的診斷服務能力？

SQL診斷最佳化服務需要具備服務於雲上百萬級資料庫例項的能力，其線上服務能力同樣面臨巨大挑戰，例如如何實現複雜的計算服務服務化拆分，計算服務的橫向伸縮，最大化的並行，資源訪問分散式環境下的併發控制，不同優先順序的有效排程消除隔離，峰值緩衝等等。

02

能力構建

面對上面提到的眾多挑戰，下面著重從DAS中的SQL診斷最佳化引擎核心技術架構以及能力測試集的構建兩個維度進一步解讀。

2.1

核心技術架構

圖1: SQL診斷最佳化引擎核心架構

上圖1是SQL診斷最佳化引擎的核心架構，它實現一套獨立於資料庫之外的最佳化器，包括自適應的統計資訊收集以及執行計劃的代價計算，以此為基礎彌補WHAT-IF核心能力缺失，自適應的統計資訊收集彌補統計資訊缺失。其具體的工作過程如下：

SQL解析與驗證：引擎對查詢語句做解析驗證，驗證輸入查詢語句是否符合標準，識別查詢語句的組成形成語法樹，例如：謂詞以及謂詞型別、排序欄位、聚合欄位、查詢欄位等，識別查詢語句相關欄位的資料型別。驗證SQL使用到的表、欄位是否符合目標資料庫的結構設計。
候選索引生成：依據解析驗證後的語法樹，生成多種候選索引組合；
基於代價評估：代價評估基於內建獨立於資料庫核心的最佳化器，獲取資料庫統計資訊，在診斷引擎內部作快取。診斷引擎內建最佳化器基於統計資訊計算代價，評估每個索引的代價以及不同SQL改寫方法下的代價評估，從而從代價選擇最優索引或SQL改寫方法。
索引合併與擇優：引擎輸入可以是一條查詢語句，也可以為多個查詢語句，或者整個資料庫例項所有的查詢語句。為多個查詢語句做索引推薦，不同的查詢語句的索引建議，以及已經存在的物理索引，有可能存在相同索引、字首相同索引、雷同索引。

2.2

能力測試集構建

如前面有關挑戰性章節所述，我們的目標是構建具有足夠覆蓋度的能力測試集，並以此為尺，度量能力，驅動能力構建。在這一過程中，如下圖2所示，我們構建了以用例系統為中心的開發模式。

圖2: 案例系統

能力測試集構建的基本思想，首先透過特徵化實現測試案例基於特徵的形式化描述，形成測試案例形式化特徵庫，並具備足夠的完備性；

在阿里巴巴集團內部，我們已經對全網資料庫例項上全部SQL進行實時採集和儲存，藉助阿里巴巴這個大平臺業務的豐富性和SQL場景的豐富行，以特徵化形式描述為抓手對線上海量全量SQL資源分析搜尋符合指定特徵的真實案例，抽取測試案例所需的資訊（注：案例庫的資料均來自阿里巴巴集團內部業務，所涉及的線上抽取資訊，如統計資訊，均經過加密脫敏處理，此過程為無人參與的全自動化過程），最終完成測試案例庫構建。

最後透過 “測試用例形式化特徵庫” 和 “測試案例庫”的特徵比對，可實現測試完備度和覆蓋度的評估，例如：

1）哪些測形式化特徵測試用例已被測試用例覆蓋，完備度是多少？

2）哪些形式化特徵測試用例，當前的診斷最佳化能力未覆蓋？或測試驗證失敗？

3）在一段時間哪些測形式化特徵測試用例出現頻繁的迴歸問題？

4）各能力級的測試用例覆蓋率怎樣？

03

真金不怕火練

DAS的SQL診斷最佳化服務雲上釋出前，已在阿里巴巴集團內部穩定執行將近3年多時間，日平均診斷量在5萬左右，很好地支撐著整個集團業務應用的SQL最佳化，使用場景應用場景主要包括：

自助最佳化：集團使用者指定問題SQL, 服務完成診斷並提供最佳化專家建議；
自動最佳化：自動最佳化服務自動識別業務資料庫例項工作負載上的慢查詢，主動完成診斷，生成最佳化建議，評估後編排最佳化任務，自動完成後續的最佳化上線操作及效能跟蹤，形成全自動的最佳化閉環，提升資料庫效能，持續保持資料庫例項執行在最佳最佳化狀態。

3年多來，SQL診斷成功率保持在98%以上，針對慢SQL的推薦率超過75%。

截止到2020年3月底，自動SQL最佳化已累計最佳化超4200萬慢SQL，集團全網慢SQL下降92%左右。

更為重要的是，SQL診斷最佳化服務已經構建了有效的主動式分析，反饋系統，線上診斷失敗案例，使用者反饋案例，自動最佳化中的回滾案例會自動迴流到案例系統，一刻不停地驅動著診斷服務在快速迭代中成長。

耗時又繁重的SQL最佳化，以後就都交給TA吧！

相關文章