4. Azure Synapse SQL池性能优化

专用SQL池（Dedicated SQL Pool）是Azure Synapse中面向大规模分析场景的MPP（大规模并行处理）引擎。它的性能并不取决于单一开关，而是由数据分布、索引结构、统计信息、缓存机制、工作负载隔离和查询计划共同决定。理解这些机制之间的配合关系，比记住某个参数更重要。

分布策略：决定数据如何在60个分布间移动

专用SQL池将每张表的数据按分布列散列到60个分布（Distribution）上。分布策略直接决定查询时是否需要跨节点搬移数据。常见选择有三类：

• 哈希分布（HASH）：适合大事实表，选择高基数、常用于JOIN或GROUP BY的列，如CustomerKey、ProductKey。分布列应避免倾斜，且尽量与常用连接键一致。
• 轮询分布（ROUND_ROBIN）：数据均匀打散，适合无明确连接键的暂存表或加载表，但JOIN时通常需要Shuffle Move。
• 复制分布（REPLICATE）：每个计算节点保留完整副本，适合小于约2GB的维度表，可消除JOIN时的数据搬移，但会放大存储与加载开销。

判断分布是否合理，可观察sys.dm_pdw_nodes_db_partition_stats中各分布的row_count差异。若最大分布与平均分布偏差超过10%，通常意味着分布列基数不足或存在热点值，需要重新评估。对于频繁参与JOIN的事实表，应优先让连接键与分布列对齐，减少ShuffleMove操作。

索引设计：聚集列存储与堆的取舍

专用SQL池默认使用聚集列存储索引（CCI），它按列压缩并批量扫描，适合大表聚合分析。对于小于约1亿行且以点查为主的表，可考虑堆表（HEAP）配合非聚集索引。CCI的COMPRESSION_DELAY参数控制行组延迟压缩，默认60分钟，适合持续小批量写入场景；若批量加载后立即查询，可设为0以尽快获得压缩收益。

索引并非越多越好。每个额外索引都会增加加载和DML成本。实践中应遵循：大事实表用CCI，小维度表用REPLICATE加HEAP，中间表用ROUND_ROBIN加HEAP。对于需要唯一约束的维度表，可使用PRIMARY KEY NONCLUSTERED配合NOT ENFORCED，既保留元数据信息又不强制校验开销。

物化视图与结果集缓存

物化视图（Materialized View）预先计算并存储聚合结果，适合重复执行的昂贵聚合查询。创建时需指定WITH (DISTRIBUTION = HASH(...))，并确保基表变更后视图能自动或手动刷新。查询优化器会自动匹配物化视图，但匹配条件较严格，包括聚合函数、分组列和连接结构需一致。

结果集缓存（Result Set Cache）则是在查询完全相同时直接返回缓存结果，无需重新计算。它适用于仪表板、报表等重复查询场景。缓存命中要求查询文本、会话设置和底层数据版本一致。若数据频繁更新，缓存命中率会下降，此时应评估是否关闭该数据库级别的缓存，或改用物化视图。

工作负载管理：分类器与资源池

工作负载管理通过CREATE WORKLOAD GROUP和CREATE WORKLOAD CLASSIFIER实现。分类器根据查询标签、用户、角色或资源类别将请求路由到不同资源池。例如，为ETL加载分配高IMPORTANCE和较大MIN_PERCENTAGE_RESOURCE，为交互式查询分配较低资源但保证CAP_PERCENTAGE_RESOURCE上限，避免单一查询耗尽资源。

CREATE WORKLOAD GROUP wg_etl
WITH (MIN_PERCENTAGE_RESOURCE = 30, CAP_PERCENTAGE_RESOURCE = 70, REQUEST_MIN_RESOURCE_GRANT_PERCENT = 5);

CREATE WORKLOAD CLASSIFIER cls_etl
WITH (WORKLOAD_GROUP = 'wg_etl', MEMBERNAME = 'etl_user', IMPORTANCE = HIGH);

分类器按定义顺序匹配，因此应将最具体的规则放在前面。可通过sys.dm_pdw_exec_requests查看classifier_name和importance，确认请求是否被正确分类。

统计信息维护与查询计划分析

统计信息是优化器估算行数、选择连接顺序和分布方式的基础。专用SQL池不会自动创建所有统计信息，需手动或通过作业定期执行CREATE STATISTICS。建议对参与JOIN、WHERE和GROUP BY的列创建统计信息，并在数据加载后更新。

CREATE STATISTICS st_CustomerKey ON FactSales(CustomerKey) WITH FULLSCAN;
UPDATE STATISTICS FactSales;

查询计划分析可通过EXPLAIN或sys.dm_pdw_request_steps查看。重点关注ShuffleMove、BroadcastMove和PartitionMove操作。若计划中出现大量ShuffleMove，说明分布键与连接键不匹配；若出现BroadcastMove且右表较大，说明复制分布表过大。通过对比不同分布策略下的计划步骤数和数据移动量，可以量化优化效果。

综合来看，专用SQL池优化是一个闭环：分布策略和索引决定数据访问路径，统计信息影响优化器决策，物化视图和结果集缓存减少重复计算，工作负载管理保障资源公平，查询计划分析则验证前四者是否真正生效。每次调整后，都应通过DMV对比数据移动量、执行时间和资源等待，确认优化方向正确，而不是仅凭单次查询变快就下结论。