Azure Synapse中是否不推荐创建临时表？其性能影响是否属实？

核心观点真实性验证 #

你同事提出的“临时表先在主节点创建完成再全量分发到子节点、因此拉低运行性能”的说法，存在明显的事实偏差，和Synapse专用SQL池的实际运行逻辑不符。

• 临时表的实际创建流程：不管是会话级本地临时表（表名带#前缀）还是全局临时表（表名带##前缀），创建时仅在控制节点（原架构中的主节点）完成元数据注册，不会预先把表对象全量推送到所有计算节点。表的数据分布逻辑和普通永久表完全一致：会按照建表时指定的分布策略（哈希分布、轮询分布、复制分布），在查询运行时直接在对应计算节点落盘存储，不存在“主节点建完再跨节点分发对象”的额外固定流程。
• 临时表和永久表的创建流程开销差异，仅来自生命周期的不同：临时表会在会话断开时自动完成清理，没有持久化的留存需求；永久表的元数据会被长期存在系统目录中。这种差异带来的创建开销差是毫秒级的，正常业务场景下根本感知不到。

“临时表性能更差”的错觉来源 #

很多人会觉得用临时表跑出来的作业更慢，本质上是错误的使用习惯导致的，不是临时表本身的设计问题：

• 元数据重复开销：临时表因为是会话隔离的，每次新会话创建临时表时，优化器需要重新为这张表生成统计信息校验逻辑、生成对应的执行计划，没法像永久表那样跨会话复用缓存的执行计划和统计信息。如果在高频循环中反复创建销毁临时表，这部分累计开销会被放大，但这是使用方式的问题，不是创建流程的设计缺陷。
• 分布策略错配：很多人建临时表时图省事直接用默认的轮询分布，没有根据后续关联查询的键调整为对应的哈希分布，也没有手动更新临时表的统计信息，导致后续查询触发大量跨节点数据移动（shuffle操作），这部分查询开销被误算成了临时表创建带来的性能损失。
• 复制型表的流程误解：如果建的是复制分布的临时表，控制节点确实会把全量表的元数据缓存到所有计算节点，方便本地查询直接读取——但这个流程和建同分布的永久表是完全一模一样的，不存在临时表比永久表多走这一步的情况。

关于“优先用永久表代替临时表”建议的适用性 #

这个建议不能一概而论，要结合实际使用场景判断：

• 以下场景临时表依然是更优选择：
  • 单会话内的一次性中间计算结果，不需要跨会话、跨用户访问的加工流程
  • 10GB以内的小规模中间结果集，临时表的自动清理机制可以省去手动 drop 表的运维成本
  • 临时数据探查、脚本调试场景，不需要留存加工痕迹的操作
• 以下场景确实更适合用永久表替代临时表：
  • 需要跨多个查询、多个会话反复复用的中间结果，反复创建临时表的累计元数据、计划生成开销已经超过了永久表固定存储的成本
  • 单表体积超过100GB的大结果集，需要提前调整分布策略、建聚集列存储索引、更新统计信息，用永久表可以避免每次会话重复做这些配置的时间成本
  • 需要权限管控、操作审计的正式数据加工链路，永久表的留存特性更符合合规要求

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