临时表上的 distkey 和 sortkey - Redshift答案

【问题标题】：distkey and sortkey on temporary tables - Redshift临时表上的 distkey 和 sortkey - Redshift
【发布时间】：2020-04-18 15:19:42
【问题描述】：

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

【问题讨论】：

标签： amazon-redshift

【解决方案1】：

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

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

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

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

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

【讨论】：

【解决方案2】：

是的，可以做到。只需将 distkey 放在表查询开始之前

创建临时表 distkey(column_name) 为（选择查询.....）

【讨论】：

请不要只发布代码作为答案，还要解释您的代码的作用以及它如何解决问题的问题。带有解释的答案通常更有帮助，质量更高，更有可能吸引投票。