Azure SQL DB/DW 系列（8）——重新認識Query Store（1）——簡介

本文屬於Azure SQL DB/DW系列
上一文：Azure SQL DB/DW 系列（7）——Query Store案例（4）——查找參數化問題
本文開始整理和總結Query Store的技術要點，以更詳細的方式簡介Query Store

Query Store優勢

  Query Store默認是關閉的，一旦開啓，它就會收集數據庫中查詢的彙總信息和工作負載的統計信息。這些數據可以用來處理問題，也可以用來建立性能基線。
  本文會做一個技術簡介，如果從頭看到現在，那麼應該對Query Store有個初步的瞭解，所以是時候再重新介紹一下Query Store。
  很多地方都說，Query Store像是一個飛行記錄盒，存儲了SQL Server的諸如運行時間，讀寫，CPU等信息，也包含了查詢計劃的信息。從SQL 2017開始，Query Store也可以使用於自動計劃修正等功能。

Query Store的用處

建立性能基線

  首先，由於其收集了大量的運行信息，可以很容易地對這些實際數據進行一個性能基線的制定。比如“總體資源消耗”這個報表，可以看到各種指標。這個報表是建立性能基線的其中一個絕佳數據來源。

  如果需要定製化一些數據，也可以使用下面的目錄視圖來查詢：

• sys.query_store_runtime_stats：運行時間的彙總數據。
• sys.query_store_query_text：在數據庫中執行過的sql文本，每個相同的文本只會存儲一次。
• sys.query_context_settings：存儲查詢使用的配置內容。如SET ANSI_NULLS ON等。
• sys.query_store_query：存儲基於文本唯一執行的所有查詢，並執行上下文設置，以便你可以跟蹤它們。
• sys.query_store_plan：以XML格式顯示查詢的預估執行計劃和執行時間統計等。
• sys.query_store_runtime_stats_interval：存儲Query Store的時間間隔。
    更多的介紹會在後續再說。

穩定性能

  上圖中的第一個報表是“迴歸的查詢”，前面
Azure SQL DB/DW 系列（5）——Query Store案例（2）——計劃迴歸中提到計劃迴歸的內容，通過這個報表，可以看到存在計劃回滾的查詢，計劃迴歸非常有可能導致性能下降，這個報表可以顯示出每個查詢的執行計劃，默認存儲最近的一個月。
  通過前面提到的兩個報表，可以看到哪些查詢的執行計劃是有問題的。在Query Store出現之前，需要用計劃嚮導來修復這類問題，但是通過Query Store可以不修改代碼的前提下實現同樣的功能。
  計劃迴歸就是SQL Server編譯一個以前已經執行過的查詢（已有計劃緩存）並且這次的執行計劃不如之前的那個，如果手動強制，需要小心帶來一些非預期的問題。如果索引和結構變化，甚至會導致執行報錯。
  另外一個報表“具有高度差異的查詢”，顯示哪些查詢在性能上不一致，這爲你提供了一種方法，告訴哪些查詢有時執行不同，並可能需要調整以便持續執行。

沒有Query Store的處理方法

  在Query Store還沒出現或者由於某種原因即使是新版本也沒用到它的時候，你可能需要用其他工具來進行問題偵查和處理。比如：

• SQL Server Profiler/SQL trace：它很有用，但是開銷巨大，用過的人應該都有感覺。微軟早已不建議使用它們，不過對於某些情況下，它們還是有不可替代的作用，比如一個沒有很好管理的環境，Default trace則是沒辦法時的辦法。
• Extended Events：從SQL 2008開始引入的以替代Profile/Trace爲目標的輕量級工具，它非常強大，在後續也會被一直強化，是服務器端處理問題的首要推薦工具之一，不過Azure環境下配置有些麻煩，特別是在完善的權限體系下，非高權限用戶配置起來可能做不到。另外不合理地使用 Extended Events同樣也會造成服務器壓力增大。
• Trace Flag：跟蹤標記，很多功能只有跟蹤標記可以實現，特別是服務器級別的配置。這裏不多做介紹，因爲這個非常專業。
• DMVs：DMVs作爲使用SQL 命令進行問題查詢是非常有用的，可以查看很多當前問題，但是它們以累積值爲主，所以並不是非常好普及，不過個人經驗中，還是主要以DMVs工具爲主。比如在SQL 2019中，開啓了Trace Flag 2451這個跟蹤標記之後，可以用下面的DMV查詢來查看正在運行的會話中，最近一次運行的實際執行計劃：

SELECT er.session_id,
       er.start_time,
       er.status,
       er.command,
       st.text,
       qp.query_plan AS cached_plan,
       qps.query_plan AS last_actual_exec_plan
FROM sys.dm_exec_requests AS er
OUTER APPLY sys.dm_exec_query_plan(er.plan_handle) qp
OUTER APPLY sys.dm_exec_sql_text(er.sql_handle) st
OUTER APPLY sys.dm_exec_query_plan_stats(er.plan_handle) qps
WHERE session_id > 50
       AND status IN ('running', 'suspended');
GO

  DMV工具很多，這個需要長期積累，不過記住他們是基於內存的，一旦服務器重啓或者內存被清空，則數據會消失。
  還有一些國外專家多年積累後編寫出來的工具，其中一個我用了4年的非常強大的工具： sp_whoisactive，只能推薦用於非雲版本的服務器中，可以自行網上搜索源碼。
  除了上面提到的之外，還有諸如Windows的性能計數器，SQL Server的等待信息，Linux的一些第三方工具等。

Query Store如何改變這種現象

  Query Store首先把數據收集在一起，同時提供了多種緯度的分析，在2019中可以按下面的緯度來統計：

• 執行次數
• 持續時間
• CPU時間
• 邏輯讀
• 邏輯寫
• 物理讀
• 物理寫
• CLR時間
• DOP：並行度
• 內存消耗
• 行數
    這些信息可以是總計、平均值、最大最小值和標準偏差。通過Query Store，我們可以用來處理下面常見的問題：
• 查找和修復迴歸的查詢
• 查找和標識最高的資源消耗查詢。
• A/B測試
• 升級SQL Server版本時的性能測試
• 查找需要優化的查詢。

  另外從SQL 2017開始（Azure已整合），引入了自動計劃修正（Automatic Plan Correction）功能，可以基於計劃迴歸自動強制計劃或者不強制計劃。

總結

  Query Store提供了自動地，簡單地收集SQL Server性能數據，可用於處理多種性能問題，接下來的幾篇文章裏面會對這些內容做擴展介紹。

下一文：Azure SQL DB/DW 系列（9）——重新認識Query Store（2）——工作原理