amazon-redshift - 临时表上的 distkey 和 sortkey - Redshift

Question

我开始对查询调优进行一些研究，并且一直在尝试使用 distkey 和 sortkey。从我读过的内容来看，如果我将 distkey 设置为连接列，查询计划器将使用合并连接而不是散列连接，这在 Redshift 中应该更快。我想知道这是否也适用于临时表？我们的生产表实际上是 View ，因此它们没有设置任何键。我不确定为什么我们不使用实际的仓库表。

Answer 1

是的，可以为临时表设置键:

create temp table fred DISTKEY (1) as ...

这很容易通过列位置来完成——在这个例子中是第一列。您还可以根据需要在临时表上设置分配方式。这样做会强制数据保留在“节点上”以获取非常大且复杂的查询中的中间结果。 Redshift 在如何分配中间结果方面做得很好，但并不完美，也不了解数据的性质。当播放大数据图像时，我已经这样做并取得了很好的效果。

关于使用 View 而不是表的第二点 - 在 Redshift 中，标准 View 基本上是 SQL 宏，由 Redshift 查询编译器展平/优化。所以使用 View 代替表本身并不坏。使用 View ，尤其是复杂的 View ，可以隐藏查询正在执行的操作，这会给查询增加不必要的和意外的复杂性。键在 View 引用的表中设置。 (我假设 View 没有引用外部/频谱表)

最后，您声明您希望实现 Merge Join 行为以提高性能。虽然这是最快的连接类型，但在临时表上进行合并连接所需的时间和工作不会被这种性能提升(经验)所抵消。 Redshift 只会在确定要连接的数据将毫无问题地“压缩”在一起时才使用合并连接。如果不能完全确定是这种情况，它必须执行哈希连接，这是一个更通用的过程。要让 Redshift 进行合并连接，您需要对临时表进行排序和分析，这将比您节省的时间花费更多的时间。让你的连接成为“DIST NONE”——没有数据的网络分布——比从散列连接移动到合并连接要重要得多。