本文是SIGMOD 2019《Automatically Indexing Millions of Databases in Microsoft Azure SQL Database》論文的筆記，個人見解。本文重點討論了Azure的自動索引推薦系統(tǒng)，討論了整個過程的細節(jié)和反饋。
1. 前言
自動索引推薦是數(shù)據庫領域里的一個研究了很久的問題，也有很多種算法提出來，但大多是基于數(shù)據表的統(tǒng)計信息或優(yōu)化器的計算方式，結合SQL語句中的查詢條件進行選擇，然后得到當前SQL所需要使用的索引。
然而，一個端到端的自動索引推薦系統(tǒng)卻很少見，尤其是在大規(guī)模運維的云上數(shù)據庫系統(tǒng)里更是沒見過有這類功能。主要挑戰(zhàn)點如下：
? ? 1. 如何大規(guī)模的應用到所有的數(shù)據庫上。Azure上數(shù)據庫覆蓋了超過140個國家，涉及了50多個全球化區(qū)域。
? ? 2. 要推薦出合適的索引。推薦索引時還有很多附加因素，如索引占據的空間大小。
? ? 3. 最好的索引推薦算法是依賴查詢優(yōu)化器組件。數(shù)據庫理論上的最優(yōu)索引與查詢優(yōu)化器實現(xiàn)過程中采用的索引不一定是一致的，而生產環(huán)境下是不接受出現(xiàn)這種badcase的。（畢竟理論是理論，實現(xiàn)是實現(xiàn)，在實現(xiàn)的過程中會權衡多種因素對理論做一定的妥協(xié)。）
? ? 4. 自動索引的操作不能影響用戶。建索引可能會鎖表、會占大量cpu或I/O。
2. 方法
本文主要是介紹了框架，包含如下幾個組件：
? ? 1. 控制面板（Control Plane）：作為整個系統(tǒng)的控制面板，掌握整個自動優(yōu)化流程的生命周期，協(xié)調不同組件。
? ? 2. 索引推薦器（Index Recommender）：分析業(yè)務的workload，識別出哪些index需要被創(chuàng)建或者是被拋棄。這里主要是微軟以前做過的兩個工具MI（Missing Index）和DTA（Database Engine Tunning Advisor）。
? ? 3. 驗證器（Validator）：分析index對workload的影響，用于檢查新的index是否產生了導致SQL性能變差的情況。
微軟的這個工作已經做了很多年，它的主要時間節(jié)點如下：
????2015年：自動優(yōu)化系統(tǒng)啟動
????2016年：整個系統(tǒng)GA
????2018年：已經百萬級別數(shù)據庫實例的應用
3. 工程方面
在工程上，為了避免數(shù)據跨region的問題，微軟在每個region都部署一個auto-index的服務節(jié)點，服務之間的調用采用了RPC調用，服務的內部細節(jié)見Figure 4。
從Figure 4的流程上可以看出，Control Plane是整個流程的核心，它發(fā)起任務后，由SQL引擎根據workload進行索引推薦，然后將建議反饋給Control Plane和用戶Portal，然后Control Plane再啟動創(chuàng)建索引和驗證索引流程，讓SQL引擎在Validator上基于Query Store的數(shù)據進行驗證，再把驗證結果反饋給Control Plane和用戶Portal。其中，該服務中的有兩個重要的節(jié)點：
SQL Server查詢優(yōu)化器。它可以產生出一些缺失的索引，也會借助“what-if” API去解決索引配置。
Query Store。這個工具將所有的SQL流水數(shù)據進行存儲，并且對不同的SQL 模板進行了統(tǒng)計，記錄了SQL層面很多維度的數(shù)據。
3.1. Control Plane
Control Plane部分管控整個流程，主要的任務就是如Figure 4里的作用：
????1. 發(fā)起數(shù)據庫診斷和生成索引
? ? 2. 應用索引推薦
????3. 驗證推薦結果
? ? 4. 檢測索引應用后的效果或告警
而推薦出的索引在整個流程中是有很多種狀態(tài)：
????Active：索引準備應用或者刪除（推薦刪除某個索引 也是索引推薦的一部分）
????Expired：索引由于生命周期原因導致的過期
????Implementing：正在執(zhí)行索引推薦的結果
????Validating：驗證應用索引建議后的效果
????Success：索引建議符合預期
????Reverting：索引建議Validate過程中出現(xiàn)性能變差的case，系統(tǒng)正在回滾
????Reverted：回滾完成
????Retry：重試
????Error：失敗
跟蹤索引建議的這些狀態(tài)是管理索引推薦流程的重要環(huán)節(jié)，這樣對數(shù)據跟蹤有很大幫助，也能快速定位問題。
3.2. Index Recommender
微軟的索引推薦器主要是兩個：MI（Missing Indexes）和DTA（Database Engine Tunning Advisor）。這兩個工作均已經發(fā)布很久，經過了線上環(huán)境的驗證。
其中，MI可以識別出數(shù)據庫中目前不存在且能提升SQL性能的索引，它通過DMV（Dynamic management view）或者執(zhí)行計劃把缺失的索引暴露出來，相對比較輕量。MI是個局部優(yōu)化，同時它不能對groupby join, order by類查詢產生優(yōu)化，并且也不能從workload視角對索引進行優(yōu)化。DTA則是一個較為完整的physical design tool級別的工具，它可以用workload作為輸入并產出基于workload級別優(yōu)化的索引建議，它也會使用 what-if 優(yōu)化器。DTA對資源的消耗比較高。因此，微軟在機型偏差的數(shù)據庫上采用MI進行推薦，對機型較好的采用了DTA進行推薦。
在workload選擇上，微軟利用QueryStore中的數(shù)據對業(yè)務workload進行排序處理，然后選擇占比較大的部分進行整體性能優(yōu)化，例如占比workload>80%以上的SQL部分。
（對于MI和DTA的更多細節(jié)處理，以及微軟在應用過程中處理的一些操作，還是看原文吧，就兩頁紙，這里不去翻譯了。只能說，這里的細節(jié)坑都是生產環(huán)境中真實要處理的地方，如workload選擇、中間表優(yōu)化、優(yōu)化器badcase等問題。）
對于索引刪除建議，這其實也是個很有難度的問題，也是生產環(huán)境中被質疑最多的地方，主要難點：
? ? 1. 很重要的偶發(fā)SQL要用的索引。這種索引通常是特定業(yè)務需求下產生的SQL。例如，每個月底才運行一次的報表SQL。
? ? 2. 用戶加了hint或者force index的查詢。在未優(yōu)化索引時，開發(fā)同學可能會通過hint或者force index來糾正某些優(yōu)化器對SQL執(zhí)行的bad case。
? ? 3. 重復索引。有些索引可能已經包含在另一個索引里，如何找出和選擇這些重復的索引，也是很困難的。因為有時優(yōu)化器的選擇跟我們理解的選擇還是有差異，會出bad case。
微軟在針對上面這3種問題上，采用了更加詳盡的索引使用統(tǒng)計、避開force index、擴大索引分析窗口長度等方法，盡可能的將影響降到最低。
3.3. Implementation and Validation
當索引推薦器產生出索引后，要對這些建議進行驗證，才能應用到線上環(huán)境。
在執(zhí)行的時間上，操作的前提是選擇業(yè)務的低峰期，進行索引變更，并且把變更索引的權重調整到最低，避免影響用戶。
在驗證細節(jié)上，評價指標值中只關注邏輯指標（cpu time、logic read等），評價對象是只分析與索引建議相關的SQL，評價方法上采用了Welch t-test來校驗索引變更前后分布是否一致。若檢測到有性能退化，則回滾。
4. 實驗階段
實驗階段，是指如何驗證索引建議的正確性。由于業(yè)務的多樣性，SQL也有很多種case需要去驗證算法的覆蓋度。
微軟采用了一個非常實用且高效的方法：B-instance。思路非常簡單：為了給A數(shù)據庫產生索引推薦，先做一個A的鏡像B，然后對鏡像B進行索引推薦并應用，這樣B就是具備新索引的節(jié)點。然后，當業(yè)務SQL執(zhí)行到A的時候，同時發(fā)送給B一份，然后觀察B節(jié)點上的性能指標，如果性能變好就說明索引建議有效。在這個過程中，創(chuàng)建鏡像B、轉發(fā)SQL流量、B節(jié)點的結果均確保對A實例和業(yè)務無影響。
這個方法僅在實驗階段用于驗證算法和方案的有效性，驗證結束后的線上生產環(huán)境中并沒有對每個數(shù)據庫均做一套B-instance方案。
4.1. 實驗結果
由于MI和DTA應用在了不同機型，因此實驗也分成了兩類建議效果的評價。
基準數(shù)據為User，即數(shù)據庫上DBA自己產生的索引。通過隨機從這些索引中扔掉索引，再讓算法MI/DTA進行推薦，然后對比前后的效果。
從Figure 6來看，MI和DTA并沒有出現(xiàn)一個完全覆蓋另一個的情況，說明了MI和DTA服務同時存在的必要性。算法推薦出的索引可以在85~90%的數(shù)據庫實例上達到甚至超過DBA調整的索引，說明了算法的有效性。在Preminum tier中User的占比高于Standard tier中User，說明在非常復雜的workload上，DBA人工的索引效果要更好一些。
5. 商業(yè)價值
截止到2018年10月，Auzre上產生了250 K的新建索引建議和3.4 Million的刪除索引建議。
在打開了自動推薦索引的數(shù)據庫上，約50K的索引被創(chuàng)建，約20K的索引被刪除。
約11%的索引建議產生了回滾。
6. 結論
微軟的工作做的非常細致，畢竟是應用在Azure全部數(shù)據庫上且運行了兩年以上的系統(tǒng)。每個基礎工作均有扎實的基礎，在確保不影響用戶的前提下也創(chuàng)新了很多操作，如低優(yōu)先級的index operation、invisible index、resumable index create等等。
