Azure Synapse多CTE视图性能优化咨询（无行级索引场景）

一、CTE 逻辑优化 #

• 把过滤条件WHERE尽量下推到最底层CTE，直接作用于源表，减少后续CTE需要处理的数据量。如果源表用了哈希分区，过滤条件要匹配分区键，触发分区裁剪，避免全分区扫描。
• 重复使用的子查询逻辑别多次定义CTE，改用临时表（CREATE TABLE #temp）存储中间结果，避免重复计算。Synapse里临时表的性能比重复调用CTE更稳定，数据量大时优势明显。
• 简化CTE嵌套层级，合并逻辑相近的CTE，减少中间数据的生成，降低查询计划的复杂度。

二、聚簇列存储索引（CCSI）优化 #

• 确保查询的过滤、聚合列是CCSI的有序列（如果定义过排序），有序列能大幅提升过滤和聚合效率。没定义的话，重建CCSI时指定常用过滤列作为排序键。
• 绝对不要用SELECT *，只返回业务需要的列。列存储索引的核心优势就是按需读列，冗余列会显著增加IO开销，700万条数据的场景下影响尤甚。
• 定期维护列存储索引，执行ALTER INDEX ALL ON [TableName] REORGANIZE合并碎片。数据写入后，列存储的行组容易出现零散的开放行组，拖慢查询速度。

三、哈希分区优化 #

• 确认查询过滤条件包含哈希分区键，触发分区裁剪，让查询只扫描相关分区。比如表按CustomerID哈希分区，视图过滤就要带上CustomerID的筛选条件。
• 检查哈希分区的基数和分布：分区数建议等于Synapse SQL池DWU数的2-4倍，每个分区数据量控制在几十GB级别。如果分区数据分布不均，重新选择基数高、分布均匀的列作为分区键（比如用户ID、订单ID）。

四、视图结构优化 #

• 非必要别用DISTINCT或GROUP BY，必须用的话，把这些操作下推到最底层数据源附近，减少处理的数据量。
• 考虑将普通视图转为物化视图，Synapse的物化视图会自动同步源表数据，预计算查询结果。对于查询模式固定的场景，物化视图能直接返回预存结果，比普通视图实时计算快很多。注意物化视图有存储和刷新成本，按需使用。

五、查询执行优化 #

• 手动指定连接方式，比如OPTION (HASH JOIN)，大表关联时哈希连接效率更高。Synapse优化器偶尔会选不合适的连接类型，手动指定能规避这个问题。
• 如果是前端展示用，别一次性返回700万条，用OFFSET ... FETCH NEXT分页查询，减少单次数据传输量。
• 用EXPLAIN查看执行计划，定位全表扫描、跨分区扫描、低效连接等问题，针对性优化。比如执行EXPLAIN SELECT * FROM YourView WHERE ...，分析扫描类型和数据处理步骤。

六、其他实用优化 #

• 临时提升Synapse SQL池的DWU（数据仓库单元），应对大查询后再降回去，平衡性能和成本。
• 别用标量UDF，标量UDF会逐行执行，700万条数据场景下会严重拖慢速度，改用表值UDF或者把逻辑直接内嵌到查询里。

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