探索查詢存放區
SQL Server 查詢存放區是一項針對資料庫的功能,可自動擷取查詢、計劃和執行階段統計資料的歷程記錄,以簡化效能疑難排解和查詢微調。 此外也提供資料庫使用模式和資源使用量的深入解析。
查詢存放區由三個存放區組成:
- 計劃存放區:儲存預估的執行計劃資訊。
- 運行時間統計數據存放區:儲存執行統計數據資訊。
- 等候統計數據存放區:保存等候統計數據資訊。
啟用查詢存放區
查詢存放區預設會在 Azure SQL 資料庫中啟用。 如果您想要將其與 SQL Server 和 Azure Synapse Analytics 搭配使用,則必須先加以啟用。 若要啟用查詢存放區功能,請使用下列適用於您環境的查詢:
-- SQL Server
ALTER DATABASE <database_name> SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE);
-- Azure Synapse Analytics
ALTER DATABASE <database_name> SET QUERY_STORE = ON;
查詢存放區如何收集資料
查詢存放區會在多個階段與查詢處理管線整合。 在各個整合點,資料會收集在記憶體中,並以非同步方式寫入磁碟,以將 I/O 額外負荷降到最低。 整合點如下所示:
查詢第一次執行時,會將其查詢文字和初始預估的執行計劃傳送至查詢存放區保存。
當查詢重新編譯時,計劃會在查詢存放區中更新。 如果重新編譯產生了新的執行計劃,則也會保存在查詢存放區中,擴充先前的計劃。 此外,查詢存放區會追蹤每個查詢計劃的執行統計資料,以供比較之用。
在編譯和檢查重新編譯階段期間,查詢存放區會識別是否有強制執行的查詢計劃。 如果查詢存放區提供的強制計劃與程序快取中的計劃不同,則會重新編譯查詢。
當查詢執行時,其執行階段統計資料會保存在查詢存放區中。 查詢存放區會彙總此資料,以確保能準確表示每個查詢計劃。
若要深入了解查詢存放區如何收集數據,請參閱 查詢存放區如何收集數據。
常見案例
SQL Server 查詢存放區可讓您深入了解資料庫作業的效能。 常見案例包括:
- 識別並修正因選取較差的查詢執行計劃而造成的效能迴歸。
- 識別和調整資源使用量最高的查詢。
- A/B 測試以評估資料庫和應用程式變更的影響。
- 確保 SQL Server 升級後的效能穩定性。
- 判斷最常使用的查詢。
- 稽核某項查詢的查詢計劃記錄。
- 識別及改善非計劃性工作負載。
- 了解資料庫中普遍存在的等候類別,以及影響等候時間的查詢和計劃。
- 在資源使用量 (CPU、I/O、記憶體) 方面分析一段時間的資料庫使用模式。
探索查詢存放區檢視
在資料庫上啟用查詢存放區之後,物件總管中的資料庫就會顯示查詢存放區資料夾。 針對 Azure Synapse Analytics,查詢存放區檢視會顯示在系統檢視底下。 查詢存放區檢視能快速提供 SQL Server 資料庫效能層面的彙總深入解析。
迴歸查詢
迴歸查詢會因為執行計劃變更而發生效能降低的情形。 預估的執行計劃可能因為許多因素而變更,包括結構描述變更、統計資料變更和索引變更。 直覺上最先想到的可能是調查程序快取,但這只會儲存查詢的最新執行計劃,且計劃可能會隨著系統的記憶體需求而收回。 不過,查詢存放區則會持續保存每個查詢的多個執行計劃,提供彈性讓使用者透過 強制執行計劃 來選擇特定計劃,以解決因計劃變更導致的查詢效能回歸問題。
[迴歸查詢] 檢視可以找出因為執行計劃在指定時間範圍內變更而造成執行計量退步的查詢。 此檢視可讓您根據選取的計量 (例如持續時間、CPU 時間、資料列計數等) 以及統計資料 (總計、平均值、最小值、最大值或標準差) 進行篩選。 然後,會根據提供的篩選列出前 25 個迴歸查詢。 依預設會顯示查詢的圖形橫條圖檢視,但您可以選擇以格線的格式來檢視查詢。
從左上方查詢窗格中選取查詢之後,計劃摘要窗格會顯示在一段時間內與該查詢相關聯的保存查詢計劃。 在 [計劃摘要] 窗格中選取查詢計劃,會在底部窗格中顯示圖形化查詢計劃。 計劃摘要窗格和圖形化查詢計劃窗格中的工具列按鈕可讓您對選取的查詢強制執行選取的計劃。 此窗格結構和行為在所有的 SQL 查詢檢視中的使用方式都是一致的。
除此之外,您也可以使用 sp_query_store_force_plan 預存程序來使用強制計劃。
EXEC sp_query_store_force_plan @query_id=73, @plan_id=79
整體資源耗用量
[整體資源耗用量] 檢視可讓您分析指定時間範圍中多個執行計量的總資源耗用量 (例如執行計數、持續時間、等候時間等等)。 轉譯的圖表是互動式的;從其中一個圖表中選取量值時,鑽研檢視會出現在新的索引標籤中,顯示與所選量值相關的查詢。
詳細資料檢視提供所選計量的前 25 個資源取用者查詢。 此詳細資料檢視會使用一致的介面,可讓您檢查相關的查詢及其詳細資料、評估已儲存的預估查詢計劃,以及選擇性地使用強制計劃來改善效能。 當系統資源競爭變成問題時,例如在 CPU 使用量達到容量時,此檢視將會十分有價值。
資源耗用量排名在前的查詢
[最耗用資源查詢] 檢視類似於 [整體資源耗用量] 檢視的詳細資料向下切入。 此檢視也可讓您選取計量和統計資料做為篩選條件。 不過,其顯示的查詢是根據所選篩選條件和時間範圍,排在前 25 個最具影響力的查詢。
在識別和改進未規劃的工作負載時,最耗用資源查詢檢視可最先指出未規劃性質的工作負載。 例如,在下圖中,系統會選取 [執行計數]計量和 [總計] 統計資料,表示最耗用資源的查詢大約有 90% 只會執行一次。
強制計劃的查詢
[使用強制計劃的查詢] 檢視可讓您快速查看具有強制查詢計劃的查詢。 如果強制計劃不再如預期般執行且需要重新評估,則此檢視就變得相當重要。 此檢視可檢閱所選查詢的所有持續中的執行計劃,如此便能輕鬆地判斷其他計劃現在是否更適合於效能。 如果是的話,便可視需要使用工具列按鈕來取消強制執行計劃。
高變化的查詢
查詢效能在不同的執行間可能會有所不同。 [高變異的查詢] 檢視包含查詢的分析,這些查詢具有所選計量的最高變化或標準差。 介面與大部分查詢存放區檢視一致,可任您查詢詳細資料檢查、執行計劃評估,以及選擇性地強制特定計劃。 使用此檢視將無法預期的查詢調整為更一致的效能模式。
查詢等候統計資料
[查詢等候統計資料] 檢視會分析資料庫使用最頻繁的等候類別,並轉譯為圖表。 此圖表為互動式圖表;選取等候類別時,會鑽研構成等候時間統計資料的查詢詳細資料。
詳細資料檢視介面也與大部分查詢存放區檢視一致,可任您查詢詳細資料檢查、執行計劃評估,以及選擇性地強制特定計劃。 此檢視可協助識別影響應用程式使用者體驗的查詢。
追蹤查詢
[追蹤查詢] 檢視可讓您根據輸入的查詢識別碼值來分析特定查詢。 執行之後,檢視會提供查詢的完整執行歷程記錄。 執行上的核取記號表示已使用強制計劃。 此檢視可以提供查詢的深入解析,例如具有強制計劃的查詢,以確認查詢效能維持在穩定狀態。
使用查詢存放區尋找查詢等候
當系統的效能開始下降時,便是查閱查詢等候統計資料以識別可能原因的合理時機。 除了識別需要微調的查詢之外,也能說明是否基礎結構的升級可能會有所幫助。
SQL 查詢存放區會提供 [查詢等候統計資料] 檢視,以提供資料庫中等候類別前幾名的深入解析。 目前有 23 個等候類別。
當您開啟 [查詢等候統計資料] 檢視時,橫條圖會顯示對資料庫影響最大的等候類別。 此外,使用位於 [等候類別] 窗格工具列中的篩選條件,便能根據總等候時間 (預設)、平均等候時間、等候時間下限、等候時間上限或等候時間標準差來計算等候統計資料。
選取等候類別會鑽研至該等候類別的查詢詳細資料。 在此檢視中,您可以調查影響最大的個別查詢。 您可以透過選取查詢窗格中的查詢,來存取 [計劃摘要] 窗格中顯示的已保存預估執行計劃。 從 [計劃摘要] 窗格中選取查詢計劃時,圖形化查詢計劃會在底部窗格中顯示。 在此檢視中,您可以強制或取消強制執行查詢計劃,以提升效能。
自動計劃修正
SQL Server 2017 和 Azure SQL Database 藉由分析查詢存放區中的資料來引進自動計劃修正概念。 當啟用包含 SQL Server 2017 (或更新版本) 和 Azure SQL Database 資料庫的查詢存放區時,SQL Server 引擎會找尋查詢計劃迴歸並提供建議。 您可以在 sys.dm_db_tuning_recommendations 動態管理檢視 (DMV) 中看到這些建議。 這些建議包括可在效能狀態良好時,手動強制執行查詢計劃的 T-SQL 陳述式。
如果您對這些建議有信心,您可以讓 SQL Server 在遇到迴歸時自動強制執行計畫。 使用 ALTER DATABASE 和 AUTOMATIC_TUNING 引數來啟用自動計劃修正。
針對 Azure SQL Database,您也可以透過 Azure 入口網站或 REST API 中的自動調整選項來啟用自動計劃修正。 啟用查詢存放區的資料庫一律會啟用自動計劃修正建議 (在 Azure SQL Database 和 Azure SQL 受控執行個體中為預設設定)。 針對新的資料庫,Azure SQL 資料庫預設會啟用自動計劃修正 (FORCE_PLAN)。

![[查詢等候統計數據] 檢視的螢幕快照,其中顯示等候類別最具影響力的查詢。](../../wwl-data-ai/explore-query-performance-optimization/media/module-55-optimize-queries-final-22.png)