Redshift 允许将多个列指定为SORTKEY列，但大多数最佳实践文档的编写方式都好像只有一个 SORTKEY。
如果我创建一个表SORTKEY (COL1, COL2)，这是否意味着所有列都按 COL1 排序，然后按 COL2 存储？或者，因为它是一个列存储，所以每一列都以不同的顺序存储？即 COL1 中的 COL1 顺序，COL2 顺序中的 COL2，而其他列无序？
我的情况是我有一个表（其中包括）一个 type_id 和一个时间戳列。数据大致按时间戳顺序到达。大多数查询都受到 type_id 和时间戳的限制。通常 type_id 子句更具体，这意味着通过查看 type_id 子句可以排除比查看时间戳子句更大比例的行。出于这个原因，type_id 是 DISTKEY。SORTKEY (type_id)我试图了解, SORTKEY (stamp), SORTKEY (type_id,stamp),的优缺点SORTKEY (stamp,type_id)。
谢谢。
如果您声明SORTKEY(COL1, COL2)，则所有列都将按 排序COL1，然后COL2就好像ORDER BY (COL1, COL2)完成了一样。
如果您正在使用SORTKEY加速 JOIN，AFAIU 没关系，只要您SORTKEY在将要连接的表上使用相同的，因为发生的是合并连接。
如果COL1像您一样具有高度选择性type_id，则意味着只有少量行具有相同的type_id. 因此，尽管您可以向 SORTKEY 添加另一列，但它的实用性有限，因为大部分行删除已经发生。
如果COL1不像您的那样具有高度选择性stamp（顺便说一句，这有点奇怪；我本来希望它比type_id? 无论如何..），这意味着过滤stamp不会消除那么多行。所以声明第二个排序键更有意义。但是，这比其他方式效率低，因为更早地消除行会更便宜。如果您有时按stamp而不是按过滤type_id，那么这样做可能是有意义的。
我们也在使用 Redshift，我们有大约 20 亿条记录（每天增加 2000 万条记录），我不得不说，sort_key 的选择性越低，它应该在 sort_key 列表中越靠前。
在我们的例子中（请注意分析您如何使用/查询自己的数据），我们使用时间戳作为第一个 sort_key。这样做的问题是，即使在 1 秒内我们记录了大约 200 行，这导致我们的 1MB 块仅包含几秒钟，并且该单个块中的每种类型的数据。意思是，尽管时间戳是高度选择性的，但在我们无法真正进一步过滤之后，因为我们在每个块中都有各种数据。
最近我们颠倒了 sort_keys 的顺序。第一个有大约 15 个不同的值，第二个有大约 30 个，等等......现在时间戳是最后一个，但是仍然以秒为单位测量一个块。
这导致，（因为我们经常使用前两个 sort_keys 作为过滤器）如下： 旧解决方案：一年的数据，选择一个月，它会丢弃 91% 的块，但在它必须打开所有块之后，甚至虽然我们想进一步过滤。
新的解决方案在第一步中丢弃了大约 14/15 的块，无论日期范围如何，然后是大约 95% 的剩余块，时间戳仍然会丢弃 91% 的剩余块。
我们用两个 8 亿条记录表对它进行了彻底的测试，除了排序键的顺序之外，它们是相同的。“where”子句中的时间段越高，我们得到的结果就越好。显然，在连接的情况下它变得更加重要。
所以我的建议是，了解你的数据库以及你经常运行什么样的查询，因为最具选择性的列可能不是最好的第一个 sort_key。正如 Enno Shioji 所说，这完全取决于您过滤的内容。
I will say the order for sort_key should be
the general rule: lower cardinality put first if same level.