我的Azure SQL数据仓库中有一个典型的星型模式。数据首先通过Data Factory转储到临时表中，然后调用一个调用其他过程的主过程将数据转换为适当的格式，然后清除该数据块的登台表。
这些登台表是否应该有索引？他们有统计数据吗？我最近升级到Gen 2，但没有打开自动创建统计信息。我担心统计数据会被创建但不会更新，因此最终会减慢速度。
对于更多上下文，有一个重建索引和更新统计信息的过程，每天运行一次。数据加载过程每小时运行一次。
鉴于这些是临时表，最大的影响将来自以下。
尽可能使用哈希分布。在后续步骤中处理表时，这将提供最佳性能。虽然文档有时会建议round_robin分发，并且这对于摄取来说稍微快一些，但表上的下一个查询将会更慢。
始终使用统计信息我建议根据预期使用情况手动创建它们，以提高ELT性能的可预测性。如果您不创建和更新统计信息，您将来会在某个时间获得可怕的性能。如果您不想承担手动管理统计信息的工作，那么一定要打开自动统计信息。
考虑将HEAP与CLUSTERED COLUMNSTORE表结构用于登台表。通常，临时表是按行进行处理的，如果使用HEAP，您可能会发现在暂存层中性能更好。这需要在您的数据上进行测试，因为提供更高性能的Gen2缓存不适用于堆表。
绝对将事实和维度表创建为聚簇列存储索引。散列分发您的事实，并复制您的维度（除非您有十亿行维度，在这种情况下，散列分布可能更合适）。
如果您正在使用CTAS算法，那么对非聚集索引的需求应该非常低。我通常只在我看到查询的性能问题时才添加索引，这是我无法通过任何其他技术解决的。
最后，确保您使用的是合理的DWU和资源类。一般的经验法则是，您不应该以低于DWU500和LARGERC的速度运行您的ELT。如果不这样做，您会发现您获得了错误的聚簇列存储索引，这将导致未来的性能问题。
我方的一些意见 - 您的事实表应该被分区。实际上你应该有一个自动创建分区的工作。事实表有多大？如果您的事实表变得太大，那么根据您的要求，如果事实表中不需要，您可以考虑引入旧表的存档。