背景
日常的數據庫優化中，在數據庫的表上創建合適的索引是解決慢SQL查詢問題的一種非常重要且常用的方案。在處理過程中，DBA或者開發人員通常會根據實例上的慢SQL信息進行優化，DAS自動SQL優化功能已經實現了根據慢SQL進行自動診斷，並創建合適的索引。但該方案會面臨如下幾個挑戰：
- 數據採集問題：一些業務SQL並沒有達到慢SQL採集的閾值（比如1s），而這些SQL查詢本身沒有很好的利用索引，查詢效率不高，仍然有很大的優化空間。在併發量增大或者表數據增多的情況下，這些查詢很容易造成實例性能突然惡化而引起故障。
- 寫入代價問題：在創建索引時通常更注重提高數據讀取的效率，而忽略索引維護對寫入性能的影響和空間佔用的成本，對於寫多讀少的表，創建太多索引反而會影響系統吞吐。
- workload變化問題：索引一旦創建，通常情況下很少變化，而業務卻一直在動態變化中。隨著業務不斷迭代變化，一些索引可能不再有SQL使用，或者使用頻率很低，此時需要引入更優的索引設計來提升數據庫的處理性能。
為了解決上述問題，DAS推出了全局Workload優化功能，它可以及時檢測到數據庫的負載變化，識別到新增SQL、執行變化的SQL以及性能不佳的SQL，並綜合考慮SQL的執行頻率和相關SQL信息，給出優化建議。
解決方案介紹
全局Workload優化，主要由三部分組成。
Workload檢測：根據數據庫實例上和Workload相關的性能指標(如RT，CPU等)以及全量SQL相關指標(執行次數、執行耗時、掃描行數等)，訓練數據模型，實時檢測Workload的SQL執行情況，從而識別新增SQL、執行變化的SQL，以及整個負載變化的週期。
如下圖所示，全量SQL執行狀況指標在period1和period2呈週期性狀態，至period3，執行狀況發生變化。全局Workload優化，根據數據訓練模型，輕鬆實現識別負載變化的時間區間。
全局診斷：全局診斷優化則根據數據庫在某一時間範圍內的全部SQL執行情況，綜合考慮SQL的查詢和寫入性能以及空間佔用情況，推薦最優索引組合，從而從SQL角度最大限度提高數據庫的性能，降低數據庫導致的問題的概率。
智能壓測：智能壓測可以回放實例上某個時間段內的全部SQL（該功能會在相關文章中詳細解讀），將全局診斷和智能壓測結合後，系統可以在測試實例上根據診斷建議自動創建索引，回放歷史流量並對比採納建議前後的SQL執行情況，生成測試報告。
具體實現
觸發時機
全局workload診斷支持用戶自定義觸發和系統自動檢測觸發兩種模式：用戶觸發可以根據業務需求制定時間區間，觸發全局診斷獲取優化建議；自動檢測會實時監測實例的負載信息，檢測到數據庫有異常SQL出現，或者發現Workload整體趨勢變化，及時觸發全局workload診斷。其中異常SQL包括：(1) 新增SQL；(2) 執行次數佔比浮動20%以上SQL；(3) 執行平均RT浮動20%以上SQL等。
通過自動檢測機制，可以幫助用戶及時發現結構設計落後於業務變化的場景，減少故障發生的概率以及資源浪費。
數據來源
全局workload診斷的數據來源是SQL審計，包括SQL類型、SQL模版、執行次數以及SQL性能信息等。SQL審計會記錄診斷時間內執行的所有SQL，因此可以發現不是慢SQL但性能欠佳的SQL問題。
關聯SQL分析
通過解析SQL模版和元數據，可以分析出SQL、表、列之間的訪問關係，從而得到可能相互影響的SQL集合。通過關聯性分析，可以有效地減少後續求解問題的複雜度，同時為索引上線後的性能跟蹤服務提供基礎的數據支持。
候選索引生成及代價評估
該模塊和後面的優化求解是全局workload優化的核心模塊。在單SQL的索引推薦中可以根據一些規則或者經驗來推薦索引，也能取得一定的效果，但基於全局workload的優化基於規則的方法就幾乎無效了，必須能夠將代價進行量化。我們基於DAS實現的外置優化器，可以做到快速準確的解析語法樹、採樣收集統計信息、生成候選索引以及計算使用某個索引的代價。
優化求解
在確定候選索引集以及索引代價的情況下，選擇最有索引集合的過程可以等價為一個揹包問題的變種。選擇某個索引的收益等價為放入揹包物品的價值，由於創建一個索引既可以給查詢帶來正收益也會對寫入和空間成本帶來副收益，因此價值可以是正數也可以是負數。揹包的容量是一個表上最多建立索引的閾值（用戶設置或系統默認，並非數據庫存儲約束）。我們的目標是使得揹包中物品價值最大。另外需要注意的是，當選擇一個索引後，它會對其他索引的價值產生影響，因此在每次迭代選擇物品時需要根據已經存在索引的情況，更新剩餘待選索引的價值。
索引I代價 = 執行次數 * （a*讀收益 - b*寫代價 - c*空間佔用）
效果驗證
為了保證優化建議的有效性，我們和智能壓測功能整合到一起，提供快速方便的驗證方案。智能壓測系統會自動搭建測試實例上並同步真實數據，然後在測試上自動採納優化建議，回放診斷時間段內的全量SQL並採集SQL執行的性能數據，最後對比生成測試報告。這種方案的好處是既保證了測試場景和線上業務的一致性，又不會對線上運行業務造成影響，同時還能預估採納建議後產生的影響。
示例
比如表1中存在6條SQL，如果獨立的看每一條SQL，得到的優化索引可能為表2中的4條索引；而從workload維度來看，索引可以合併為表3的兩條索引。兩種結果對比，整體RT下降14.45%，索引空間節省50%。
SQL2 ： idx_is_deleted_gmt_modified (is_deleted, gmt_modified)
SQL4 : idx_name(name)
SQL5: idx_name_id_birth_date (name, id, birth_date)
SQL6: idx_name_nick_name （name, nick_name）
idx_is_deleted_gmt_modified (is_deleted, gmt_modified)
idx_name_id_birth_date (name, id, birth_date)
未來計劃
全局Workload優化未來會打造自動優化的閉環，包括workload異常檢測、全局workload診斷、智能壓測效果評估，自動採納建議、效果跟蹤及異常處理。另外，目前全局workload優化考慮了SQL執行頻率，SQL查詢和寫入的影響，但沒有考慮固定參數或者參數傾斜等問題，後面可以進一步將這些業務屬性納入到考慮因素當中。
相關閱讀：
數據庫自治服務DAS發佈年度新版本：1-5000，”數據庫自動駕駛“進入規模化時代
深度技術揭祕 | 大促狂歡背後，如何有效評估並規劃數據庫計算資源？
重磅 | 數據庫自治服務DAS論文入選全球頂會SIGMOD，領航“數據庫自動駕駛”新時代