用執行計畫分析查詢行為

執行計畫是什麼，又不是什麼#

執行計畫（execution plan）是觀察優化器決策的最佳窗口——它記錄查詢使用的 join 種類、用了哪些索引、用法是什麼。

執行計畫不是效能量測。計畫上的「成本」永遠是估算值（estimate），不是實際運行的測量結果。

執行計畫在所有 SQL Server 平台通用：Azure SQL Database、SQL Server 2025、AWS RDS、Azure Managed Instance 看到的格式都一樣，只是新功能會以新運算子（operator）型式出現。

Estimated vs. Actual：常見誤解#

SSMS 把計畫分成「Estimated」與「Actual」兩個按鈕，但這是 歷史遺留的命名。

執行計畫只有一種。所謂「Actual Plan」其實只是「執行計畫 + 執行階段量測（runtime metrics）」。
從 DMV、Extended Events、Query Store 拿出來的計畫，與「Actual Plan」對同一查詢（沒發生 recompile）的 計畫本身完全一致——差別只在有沒有附加 runtime metrics。

附加的 runtime metrics 包含：

等待統計（wait statistics）
查詢時間
實際列數（actual row counts）
各運算子的實際執行次數

擷取 runtime metrics 同時量測查詢效能會互相干擾。抓計畫就不要量效能、量效能就不要抓計畫。

擷取執行計畫的四種方法#

1. SQL Server Management Studio（SSMS）#

不執行查詢只取計畫：工具列「Display estimated execution plan」按鈕，或 Ctrl + L
執行查詢並附加 runtime metrics：工具列「Include actual execution plan」按鈕，或 Ctrl + M

Figure 4-1: SQL Editor toolbar with the Display estimated execution plan button

Figure 4-3: SQL Editor toolbar with the Include actual execution plan

同時 highlight 多條語句會每條都產出一個計畫。要單看一個查詢，先選取再按按鈕。

Figure 4-2: Highlighted query and the execution plan

Figure 4-4: However, the results tab will be the one open by

2. Dynamic Management Views#

SELECT dest.text,
       deqp.query_plan,
       deqs.execution_count,
       deqs.total_elapsed_time,
       deqs.last_elapsed_time
FROM sys.dm_exec_query_stats AS deqs
    CROSS APPLY sys.dm_exec_query_plan(deqs.plan_handle) AS deqp
    CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
WHERE dest.text LIKE 'SELECT ...';

query_plan 在結果中顯示為可點開的 XML，點下去 SSMS 會直接開啟為圖形計畫——但不會有 runtime metrics，因為 plan cache 不存量測值。

Figure 4-5: Results of querying the plan cache with a DMV

Figure 4-6: An execution plan with runtime metrics

XML 有巢狀深度上限（nesting limit）。極大計畫可能無法用 sys.dm_exec_query_plan，要改用 sys.dm_exec_text_query_plan，把結果存成 *.sqlplan 檔再用 SSMS 開。

取得「最近一次 actual plan」#

啟用輕量級 statistics profiling：

ALTER DATABASE SCOPED CONFIGURATION SET LAST_QUERY_PLAN_STATS = ON;

然後使用 sys.dm_exec_query_plan_stats(plan_handle)。

不保證每次都拿得到：

計畫必須還在 sys.dm_exec_cached_plans 裡
過於簡單的查詢可能只回傳根運算子
計畫被踢出快取就一起消失

3. Query Store#

SELECT qsq.query_id,
       qsq.query_hash,
       CAST(qsp.query_plan AS XML) AS QueryPlan
FROM sys.query_store_query AS qsq
    JOIN sys.query_store_plan AS qsp
        ON qsp.query_id = qsq.query_id
    JOIN sys.query_store_query_text AS qsqt
        ON qsqt.query_text_id = qsq.query_text_id
WHERE qsqt.query_sql_text LIKE 'SELECT ...';

Query Store 把 plan XML 存在 VARCHAR(MAX) 欄位，需要 CAST 成 XML 才能在 SSMS 開啟。Query Store 也不存單次 runtime metrics——它記錄的是聚合結果。

Figure 4-7: Retrieving an execution plan from the Query Store

4. Extended Events#

可用的事件：

query_post_compilation_showplan：編譯後（不含 runtime metrics）
query_pre_execution_showplan：優化後、執行前
query_post_execution_plan_profile（SQL Server 2017+）：使用輕量級 profiling，含 runtime metrics
query_post_execution_showplan：執行後，含 runtime metrics