我的维数变化缓慢，代表着我们所有文章主数据的变化，而且非常庞大：150亿行并且还在不断增长。
该表格目前分布在自然合奏上，例如（国家/地区，供应商）。
由于表的性质，使用该表的大多数查询都是范围联接，例如对不断变化的商品属性进行琐碎的订单计数：
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 /目前大约有150亿行，并且汇总特定时间戳记需要1分钟；但我想将其降低到20秒
答案 0 :(得分：2)
很好的问题。
有点背景，排序键有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之类的谓词中使用这些字段，则更为有用。
您最多可以优化这种范围联接，因为数据库必须将其视为笛卡尔乘积（也称为“交叉联接”-将a的每一行与{ {1}}）。您知道，该联接将匹配单个行，但是数据库不知道。
在全尺寸DW中，我将制作一个b代理密钥。该值将解析为SCD中的一个值。但是，这使ETL流程复杂化，因为您必须在处理过程中插入代理密钥。
您可以做的另一件事是使用article_sk列分发两个表。这样就可以在每个切片上并行完成连接。但是，article可能不是article事实表的自然分布键（通常是orders或customer）。