我正在查看我在Redshift中做的一些查询的性能，并注意到我在文档中找不到的东西。Redshift没有执行合并连接与交错排序键
我创建了两个表之间有一个连接键（子表中的约10K行）。
对于父表，我们把它称为A，我有一个主键，我声明它是表的分隔键和排序键。我们称这个ID。
对于子表B，我创建了一个外键字段parent_id，它引用了A.id. parent_id已被声明为表B的distkey。表B还有一个主键，我定义的id。我在表B上为（parent_id，id）创建了一个交错排序键。
当我尝试做一个解释加入两个表时，我总是会得到一个哈希联接。如果我用正常的复合排序键重新创建表B，我将总是得到一个合并连接。
当我查看表格的统计信息时，我看不到任何偏差。
我的问题是，Redshift会不会总是使用带交错排序键的哈希连接，或者我做错了什么？
编辑 - 表B中交错排序键的顺序实际上是（parent_id，id）。我在上面写错了。我已经更新了上面的内容，现在已经清楚了。
从我的理解：
正如您所指出的那样，如果使用普通组合键对表进行排序，则两个表都按连接列进行排序。
但是，在交叉连接中，值不可保证在每列中排序为。
Interleaved Keys为文档说：
一种交错的种类给予相等的权重至每个列，或列的子集，在排序键。如果多个查询对过滤器使用不同的列，那么通常可以通过使用交错排序样式来提高这些查询的性能。当查询在辅助排序列上使用限制性谓词时，与复合排序相比，交叉排序显着提高了查询性能。
但是，它确实不意味着所有列进行排序（因为它们是用复合排序）。相反，它给出了排序的一般良好混合，因此对任何列的排序通常都很好。因此，每列不一定要完全排序，因此需要一个哈希连接。
博客文章Quickly Filter Data in Amazon Redshift Using Interleaved Sorting试图解释在使用交错排序时如何存储数据。
这似乎意味着使用交叉排序意味着放弃合并连接，或者减少查询计划程序可以使用此类连接的情况。 – rchawdry
是的，但是通过在多个列中使用通常良好的区域映射（允许Redshift避免从多个磁盘块读取数据）而获益。如果您经常独立使用几个不同列上的WHERE子句，则只能使用Interleaved。 –
我怀疑您的交错密钥导致问题的顺序。尝试先放入'parent_id'。 –
感谢您的回复。我实际上首先使用parent_id声明了表B - 我只是没有写上面的内容。我已经做了一个修改来澄清，因为合并连接仍然不会发生。 – rchawdry
嗯，当然，这似乎是'INTERLEAVED'的问题。每当我尝试过它时都会遇到问题（请查看Redshift论坛），所以我一直在远离它，除非我真的需要它。 –