如何在Azure Synapse Analytics中获取详细查询性能指标？

1. 查询系统动态管理视图(DMV)获取细粒度执行数据 #

直接通过T-SQL查询Synapse内置的DMV，能拿到比门户更详细的运行时指标，包括CPU消耗、IO统计、数据移动量、每个执行步骤的耗时等：

• 核心DMV组合示例：

SELECT
    r.request_id,
    r.start_time,
    r.end_time,
    r.total_elapsed_time,
    s.step_index,
    s.operation_type,
    s.total_elapsed_time AS step_elapsed_time,
    s.rows_processed,
    s.data_moved,
    w.wait_type,
    w.wait_duration_ms
FROM sys.dm_pdw_exec_requests r
JOIN sys.dm_pdw_exec_steps s ON r.request_id = s.request_id
LEFT JOIN sys.dm_pdw_resource_waits w ON r.request_id = w.request_id
WHERE r.request_id = '你的查询Request ID' -- 替换为实际请求ID
ORDER BY s.step_index;

• 重点关注：data_moved（优化后直通查询应大幅减少数据移动）、step_elapsed_time（看哪个步骤占比最高）、wait_type（排查是否有资源等待瓶颈）。

2. 启用并利用查询存储(Query Store) #

Synapse SQL池支持查询存储，可自动捕获查询的执行计划、运行时统计和资源使用数据：

• 启用查询存储（T-SQL方式）：

ALTER DATABASE [你的数据库名] SET QUERY_STORE = ON;

• 查询历史性能数据：

SELECT
    q.query_id,
    q.query_text_id,
    rt.runtime_stats_id,
    rt.first_execution_time,
    rt.last_execution_time,
    rt.total_worker_time,
    rt.total_logical_reads,
    rt.total_logical_writes
FROM sys.query_store_query q
JOIN sys.query_store_runtime_stats rt ON q.query_id = rt.query_id
WHERE q.query_text LIKE '%你的查询特征%'; -- 替换为查询的关键特征

• 对比优化前后查询的total_worker_time（CPU总消耗）、total_logical_reads（IO总消耗），验证资源效率提升。

3. 生成实际执行计划查看运行时细节 #

不要仅依赖explain的预估计划，生成实际执行计划能看到算子真实的执行数据：

• 在SSMS或Azure Data Studio中执行查询时，勾选「Include Actual Execution Plan」（快捷键Ctrl+M），或执行：

SET SHOWPLAN_XML OFF;
SET STATISTICS XML ON;
-- 执行你的查询
SET STATISTICS XML OFF;

• 重点查看每个算子的Actual Rows、CPU Time、Elapsed Time，对比预估与实际的差异，判断是否因统计信息过时导致预估成本不准。

4. Synapse Studio的查询详情分析 #

在Synapse Studio的「监控」->「SQL池」->「查询活动」中，点击目标查询进入详情页：

• 查看「详细信息」标签：可拆解每个执行步骤的节点分布、数据处理量、耗时，能直观看到是否存在数据倾斜、DMS数据移动瓶颈；
• 查看「等待事件」标签：了解查询执行过程中是否存在锁等待、IO等待或资源争抢，这些是门户概览页看不到的细节。

5. 节点级资源使用统计 #

查询节点级性能计数器，了解实例整体资源负载：

SELECT
    counter_name,
    instance_name,
    cntr_value
FROM sys.dm_pdw_nodes_os_performance_counters
WHERE counter_name IN ('%CPU%', '%Disk Read%', '%Disk Write%', '%Memory%');

• 对比优化前后查询执行期间的节点CPU、内存、磁盘IO使用率，确认资源效率是否提升。

关于“预估成本下降但执行时间未变”的补充说明 #

你遇到的情况可能由以下原因导致：

• 查询瓶颈在结果返回阶段：300万行数据传输到客户端的耗时占比高，掩盖了查询执行阶段的效率提升；
• 资源分配一致：优化前后查询使用了相同的资源类(Resource Class)或DWU配额，CPU/内存资源未受限，因此执行时间差异不明显；
• 统计信息过时：预估计划的成本计算基于旧的统计数据，与实际执行情况存在偏差。

内容的提问来源于stack exchange，提问作者James Cockayne