临时表设计以提高性能

Question

我的Azure SQL数据仓库中有一个典型的星形模式。数据首先通过Data Factory转储到临时表中，然后调用主过程，该主过程调用其他过程将数据转换为适当的格式，然后清除该数据块的临时表。

这些登台表是否应具有索引？他们应该有统计资料吗？我最近升级到第2代，但是没有启用自动创建统计信息。我担心统计信息会被创建但不会被更新，因此最终会使事情放慢速度。

有关更多上下文，有一个重建索引和更新统计信息的过程，该过程每天隔夜运行一次。数据加载过程每小时运行一次。

Answer 1

鉴于这些是临时表，最大的影响将来自以下内容。

在可能的情况下，使用哈希分布。在后续步骤中处理表格时，这将提供最佳性能。尽管文档有时会建议使用round_robin分发，并且这种方式对于接收而言会稍快一些，但表上的下一个查询会更慢。

始终使用统计信息。我建议根据预期的使用情况手动创建它们，以提高ELT性能的可预测性。如果您不创建并更新统计信息，那么将来某个时候您将获得可怕的性能。如果您不想承担手动管理统计信息的工作，则一定要启用自动统计信息。

请考虑将HEAP与CLUSTERED COLUMNSTORE表结构用于登台表。通常，登台表是在整行的基础上处理的，如果使用HEAP，您可能会发现在登台层的性能更好。这需要对您的数据进行测试，因为具有更高性能的Gen2缓存不适用于堆表。

绝对将事实和维度表创建为群集的列存储索引。哈希散布您的事实并复制维度（除非您有十亿行维，在这种情况下散列分布可能更合适）。

如果您使用CTAS算法，则对非聚集索引的需求应该非常低。通常，只有在看到查询的性能问题时，才添加索引，而其他任何技术都无法解决该问题。

最后，请确保您使用的是合理的DWU和资源类。一般的经验法则是，您的ELT的运行速度不应低于DWU500和LARGERC。如果不这样做，则会发现群集列存储索引不正确，这将导致将来的性能问题。

Answer 2

我这边的一些建议- 您的事实表应已分区。实际上，您应该有一份实际上可以自动创建分区的工作。 事实表有多大？如果事实表太大，那么根据您的需求，如果事实表中不需要的话，您可以考虑引入旧表的归档。