我代表我们所有的文章masterdata变化的缓慢变化的维度，是相当庞大：15亿行和增长。
该表是目前分布在自然合奏等（国家，供应商）。
因为表的性质，大多数查询使用它的范围加入，如通过改变文章属性trivaially计数订单：
SELECT x.article_id, x.changing_article_season, COUNT(*) counting_orders
FROM article_slow_changing_dimension x
LEFT JOIN orders y ON x.article_id=y.article_id
AND y.order_timestamp BETWEEN x.from_timestamp AND y.to_timestamp
有什么能为这里的排序键选择一个有趣的策略？我在想这样做SORTKEY（from_timestamp，TO_TIMESTAMP），但我不知道。
我尝试了一些东西，但任何测试需要很长的时间来建立，实际上是很难凭经验评估。任何想法？
编辑：添加基于注释1一些细节/表的真空2 /集群是非常小的（4个节点）和查询运行非常快，但它不是在生产，因此基本上只有我跑几个查询的开发者。我想才去生产3，优化/还有约15个十亿行，现在，聚集特定时间戳服用1分钟;不过，我想推下来，以20秒
大的问题。
一点背景，排序键有2个主要目的：1）最小化从磁盘扫描数据和2）使得大表之间的连接使用一个合并连接（最快加入）。 https://docs.aws.amazon.com/redshift/latest/dg/query-performance-improvement-opportunities.html
SORTKEY(from_timestamp, to_timestamp)通常是一个非常不错的选择，但它不会提高您的示例查询的性能。这是在你喜欢WHERE from_timestamp > '2019-01-01' AND to_timestamp < current_date谓词使用这些场的情况下更有帮助。
还有就是多少，你可以优化这样的范围加入，因为数据库必须把它像一个笛卡尔积的限制（又名“CROSS JOIN” - 加入从a每一行与每一b行）。你知道，参加将匹配单个行，但数据库不知道。
在全尺寸DW我会做一个article_sk代理键。该值将解决在SCD一个值。这个复杂的ETL过程，但因为你必须注入处理过程中的代理键。
你可以做的另一件事是分配使用article列两个表。允许加入要对并行每片完成。然而，article可能不会对你的orders事实表的自然分布的按键（通常这将是customer或account）。