簡介
從名字來看，Query Store就是查詢存儲，存儲了查詢（不僅限於SELECT，還包括 DML 語句如 SELECT、INSERT、UPDATE、DELETE、MERGE 和 BULK INSERT的計劃。）的執行信息，供後續分析。它可用於SQL Server（本地版），微軟PaaS版本的SQL DB和SQL DW。
在過去，如果數據庫卡頓，從出現問題到報告給我，可能已經過了半個小時，當我登錄服務器的時候，很有可能現象消失，非常難找原因。後來有一些工具可以把信息自己存到一個實體表，但是如果你做過就知道，特別是存儲執行計劃，不僅獲取慢，而且存儲空間極大，我當初的系統，一天的執行計劃存到表裏大概是200G，比數據庫本身還大。顯然不現實，也不利於分析。
再後來，有了類似擴展事件和第三方工具來輔助，情況纔有所緩解。不過還是不夠完善。自從Query Store出現之後，我感覺很多問題都可以迎刃而解。
我們知道分析性能問題的時候，最重要的就是執行計劃，Query Store不僅存放，還存放多個執行計劃，這種多個執行計劃可能由於當時的資源使用率（有可能並行），參數變化（參數嗅探等）導致了同一個SQL 不同的執行計劃，這些它都存儲。
存儲的目的是爲了後續分析，所以它也提供了比較多的分析功能。比如按時間分割窗口等。後續會演示。
啓用
默認情況下，新的數據庫是沒有啓用Query Store的。所以你需要額外啓用。可以使用下面命令開啓：
ALTER DATABASE [數據庫名] SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE);
或者在非master/tempdb(Azure SQL DB看不到TempDB)的數據庫中右鍵選擇屬性：
作用
由於數據庫環境的變更，包括對象的變更，還有內存壓力等原因，都會導致執行計劃只能緩存最新版本，甚至連緩存久一點都不行，爲了能夠找到過往發生的內容，Query Store會存儲儘可能多的執行計劃。可以通過自動或手動強制某個執行計劃（計劃強制）作爲特定查詢的指定執行計劃，從而改變該查詢的運行情況。不過並不是一定有用。
執行計劃用於分析特定查詢的執行情況，而等待統計信息可以從更高層次或者更深入的層次中發現實例級別的問題。過去統計信息主要用於實例級別。而且以累加值爲主，從SQL 2017和Azure SQL DB開始，query store已經包含了語句級別維度的統計信息。不過需要啓用：
ALTER DATABASE [DBName] SET QUERY_STORE (OPERATION_MODE = READ_WRITE, WAIT_STATS_CAPTURE_MODE = ON)
GO
或者在界面操作;
啓用之後，可以用Query Store來：
- 快速查找和修復執行計劃
- 在特定時間段查詢的執行次數，執行次數是很重要的，對只執行一次的查詢，只要沒有明顯影響，我們一般不會花太多時間去檢查。對於執行次數非常多的，哪怕只提升一秒，對系統的整體性能而言都是有幫助的。
- 在過去某幾個小時內的前n個查詢（按資源消耗等排序）
- 分析特定資源的使用情況。
- 確定等待資源的前n個查詢。（這個很多工具都能做，不過集成在一起還是好的）
- 查看特定查詢的執行計劃的等待情況。
Query Store下面又分了三種存儲類型：
- 計劃存儲：用於存儲執行計劃信息。
- 運行時統計信息存儲：用於保存執行過程的統計信息。這個很有價值，畢竟執行過程的數據最能反映問題。
- 等待統計信息存儲：用於保存等待統計信息。
Azure SQL DB上的Query Store
上面已經大概瀏覽了一下通過SSMS找到Query Store，但是其實Azure上的Query Performance Insight也就是上一篇中第二部分，就是以Query Store爲基礎的。不過基於它的單獨存在，所以計劃後續再介紹。
我不怎麼喜歡過多的理論，雖然我知道非常重要，不過先來看點案例可能能夠提起興趣，接下來的幾篇文章我會在SQL Server On Linux 2019上做實驗，這樣不一定要用到Azure，可以更好地有一個大概的瞭解。
下一文：Azure SQL DB/DW 系列（4）——Query Store案例（1）