Redshift允许将多个列指定为SORTKEY列，但大多数最佳实践文档都被编写为好像只有一个SORTKEY。
如果我使用SORTKEY (COL1, COL2)创建一个表，这是否意味着所有列都按COL1排序，然后是COL2？或者，因为它是一个柱状存储，每列都以不同的顺序存储？即COL1顺序为COL1，COL2顺序为COL2，其他列无序？
我的情况是我有一个表（其中包括）type_id和timestamp列。数据大致按时间戳顺序到达。大多数查询都由type_id和timestamp加入/限制。通常，type_id子句更具体，这意味着可以通过查看type_id子句而不是通过查看timestamp子句来排除更大比例的行。因此，type_id是DISTKEY。我试图了解SORTKEY (type_id)，SORTKEY (stamp)，SORTKEY (type_id,stamp)，SORTKEY (stamp,type_id)的利弊。
感谢。
答案 0 :(得分：19)
如果您声明SORTKEY(COL1, COL2)，则所有列将按COL1排序，然后COL2排序，就像ORDER BY (COL1, COL2)完成一样。
如果您正在使用SORTKEY来加速JOIN，那么AFAIU无关紧要，只要您在要加入的表上使用相同的SORTKEY，因为会发生什么是合并连接
如果COL1与type_id一样具有高度选择性，则表示只有少量行具有相同的type_id。因此，虽然您可以向SORTKEY添加另一列，但其实用程序是有限的，因为大多数行已经消除。
如果COL1没有像你的stamp那样具有高度选择性（这有点奇怪btw;我本以为它会比type_id更具选择性？无论如何......），它意味着按stamp过滤不会消除那么多行。因此，声明第二个排序键更有意义。然而，这比其他方式效率低，因为先前消除行会更便宜。如果您有时按stamp而不是按type_id进行过滤，则可能会这样做。
答案 1 :(得分：15)
我们也在使用Redshift，我们有大约20亿条记录（每天+20万条记录），我不得不说，sort_key的选择性越低，sort_key列表中的记录就越多。
在我们的案例中（并建议分析您如何使用/查询自己的数据）我们使用timestamp作为第一个sort_key。问题是，即使在1秒内我们记录了大约200行，这导致我们的1MB块仅包含几秒钟，并且该单个块中的每种类型的数据。这意味着，即使时间戳是高度选择性的，我们也无法真正过滤，因为我们在每个块中都有各种数据。
最近我们颠倒了sort_keys的顺序。第一个有大约15个不同的值，第二个有大约30个等等...时间戳现在是最后一个，但是仍然只有一个块在几秒钟内测量。
这导致（因为我们经常使用前两个sort_keys作为过滤器）以下内容： 旧解决方案：一年的数据，选择一个月，它会下降91％的块，但是必须打开它们之后，即使我们想要进一步过滤。
新解决方案在第一步中下降了大约14/15的块，无论日期范围如何，其余约95％，时间戳仍然下降了91％。
我们已经使用两个8亿条记录表彻底测试了它们，除了排序键的顺序外，它们是相同的。 'where'子句中的时间段越长，我们得到的结果就越好。在连接的情况下它显然更加重要。
所以我的建议是，了解您的数据库以及经常运行的查询类型，因为最具选择性的列可能不是最好的第一个sort_key。正如Enno Shioji所说，这完全取决于你过滤的内容。
答案 2 :(得分：3)
我会说sort_key的订单应为
一般规则：如果相同级别，则首先放置较低的基数。