DW100c规格Synapse专用池小数据集查询缓慢问题咨询

你的判断完全正确，当前30万行级别的数据量完全不在Synapse专用SQL池（原Azure SQL DW）的设计适用场景内，性能低于小规模Azure SQL DB是架构特性导致的正常现象，和表分布策略配置正确性没有强关联。

性能倒挂的根本原因 #

• MPP架构的固定开销：Synapse专用池是典型的大规模并行处理架构，所有查询都要经过控制节点生成分布式执行计划、分发任务到计算节点、节点间数据Shuffle、最终结果汇总的全流程，这部分分布式调度、跨节点网络传输的开销是恒定存在的。当数据集规模足够大（通常单事实表千万行以上、整体数据集TB级）时，多节点并行计算的收益会完全覆盖这部分固定开销；但在30万行的小规模数据场景下，采用SMP架构的Azure SQL DB没有分布式调度成本，单节点本地计算的效率天然更高。
• 低DWU规格的算力限制：DW100c是专用池的最低入门规格，仅分配1个计算节点，等效算力为1vCore，本身单节点计算能力就低于你之前使用的2核Azure SQL DB，再叠加MPP架构的固定调度开销，查询耗时达到Azure SQL DB的3倍左右完全符合预期。即便扩容到DW500c，也只是提升单节点算力、增加计算节点数量，分布式调度的固定开销依然存在，针对小数据集查询的性价比极低。
• 引擎优化方向差异：Synapse专用池的存储引擎、查询优化器都是面向大吞吐量批量扫描、大宽表聚合分析场景设计的，默认以列存索引为核心存储结构，对小数据量的点查、小结果集聚合、短查询的优化优先级远低于面向OLTP/小规模混合负载设计的Azure SQL DB。即便给小表配置行存索引，优化器的执行计划生成规则依然是面向大规模分析场景，小查询的执行效率天然不占优势。

当前场景的优化建议 #

• 如果数据集长期保持在百万行级别，不要使用专用SQL池承载业务，替换为Synapse无服务器SQL池或直接使用Azure SQL DB即可，等后续数据量增长到单事实表千万行以上、整体数据集规模到百GB级后再迁移到专用池，才能真正发挥MPP架构的性能优势。
• 如果必须在当前DW100c规格下运行现有存储过程，可通过以下方式降低不必要的开销：
  • 所有频繁参与关联的维度表统一设置为REPLICATE分布，彻底消除查询过程中的节点间数据移动
  • 手动为所有参与JOIN、WHERE过滤、GROUP BY聚合的字段创建统计信息，Synapse专用池默认不会自动创建列级统计信息，统计信息缺失会导致执行计划严重偏差，是迁移后性能骤降的最常见诱因
  • 存储过程逻辑尽量减少多步临时表写入，避免触发不必要的数据重分布，能通过CTE一次性处理的逻辑不要拆分
  • 开发测试场景可开启result_set_caching，重复运行相同逻辑的存储过程时会直接命中缓存结果，能大幅缩短运行时间
• 不要为小数据量场景盲目提升DWU规格，DWU扩容仅对可充分并行化的大规模扫描查询有线性性能收益，对小查询的性能提升边际效应极强，成本投入完全不成正比。

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