本文屬於Azure SQL DB/DW系列
上一文：Azure SQL DB/DW 系列（8）——重新認識Query Store（1）——簡介
本文介紹Query Store的技術內幕
數據來源
Query Store中的數據由三個部分的數據來源組成：
- 查詢和計劃的信息：有關查詢本身的數據以及查詢優化器從該查詢派生的執行計劃的數據。
- 查詢的運行時信息：查詢運行得多快，被調用了多少次，以及在運行的時候性能相關信息。
- 查詢的等待信息：收集查詢在運行時的相關等待信息。
收集查詢和計劃的信息
當一個查詢（不僅限於SELECT）提交到SQL Server時，會經過一系列的處理過程，這些過程包括校驗SQL及需要用到的對象，但是最重要的就是進行優化，並且儘可能快地生成執行計劃，同時執行計劃也要是足夠優秀的。大概流程如下：
Query Store僅收集DML信息，這些DML包括SELECT/UPDATE/DELETE/INSERT等，而DDL是不會被收集的。至少目前不會。
再看下圖，當查詢被編譯和分析優化後生成了執行計劃，就會有一個異步的過程獲取查詢和執行計劃的信息發給Query Store。這個過程首先會把信息臨時存放在內存中，然後在一定間隔（Query Store中可定義）後再異步寫到磁盤。這一方面是爲了減輕過多實時操作對服務器的壓力，另外一方面是減少對優化過程的干預。不過有個例外，就是強制計劃，這個過程會干擾正常的優化過程，如果查詢已經應用了計劃強制，那麼會把強制後的計劃寫到緩存中，而不是由優化器產生的執行計劃。
這個過程是獨立的語句級別的，不是基於存儲過程或者批。如果查詢是屬於某個對象（存儲過程、批），那麼對象的ID也會帶進收集的信息裏面。
收集查詢的運行時和等待信息
在獲取了執行計劃之後，就會收集運行時的統計信息和等待信息，當然，只有在真正運行的時候纔會產生這些信息，也就是說在運行的時候纔會收集。這些數據會存在內存中大概15分鐘，纔會寫到磁盤。
在收集了一次信息之後，因爲重編譯導致重新生成執行計劃。如果跟Query Store中的一樣，那麼只會更新統計信息。如果因爲重編譯產生新的執行計劃，那麼新的執行計劃也會被捕獲到Query Store中。
因爲收集的數據先到內存再到磁盤，所以可能會出現異常丟失，比如服務器被重啓或者內存被清空。你可以手動使用sys.sp_query_store_flush_db來刷到磁盤。
讀者可能會覺得爲什麼要把看上去是一起查詢的運行時和等待信息分開收集，因爲Query Store從2016出現，在2016和2017時才加入了等待的統計信息，所以當時需要分開來看。另外這兩個信息雖然收集的時間接近一致，但是很多時候分析是需要分開的。
接下來我們進入更加深入的介紹。
查詢和查詢計劃信息
這部分的信息，可以從下面四個目錄視圖中獲取：
- sys.query_context_settings：關於查詢運行的上下文配置。
- sys.query_store_query：這是關係中最核心的部分，把其他三個目錄視圖連接起來。
- sys.query_store_query_text：存儲了查詢的文本信息。
- sys.query_store_plan：這個視圖存儲了查詢的執行計劃，通過外鍵query_id和sys.query_store_query關聯。
它們之間的關係如圖，在後面文章中會一邊介紹一邊演示。
運行時信息
涉及的目錄視圖有：
sys.query_store_runtime_stats通過plan_id和runtime_stats_interval_id和其他兩個表關聯。其實從這些表關係中我們也可以學習一些數據庫設計的理念。
sys.query_store_runtime_stats有很多我們感興趣的列，比如duration（持續時間），CPU time，行數，內存等。
sys.query_store_runtime_stats_interval這個視圖中，execution_type會影響信息的收集，它有三個值：0——成功執行；3——用戶終止執行；4——意外終止執行。
等待統計信息
目錄視圖的關係如下：
和運行時信息一樣，他們是按照運行時間隔來彙總數據。同時和運行時信息一樣每15分鐘刷一次內存數據到磁盤中。
總結
本文介紹了Query Store的三個組成部分，通過這三個部分，查詢的運行情況被分開來收集和存儲。