谁能帮助更深入地解释表重新分配在 AWS Redshift 中的工作原理？我从 AWS Redshift 官方文档中读到，该文档说，只要查询中所需的行尚未位于同一位置，查询优化器将始终尝试重新分配表以将行放在同一位置。如果是这样，那几乎是真的，每次出现不可预测的查询时，它们都会导致 AWS Redshift 查询优化器重新分配数据，因为每个查询的所有行位于同一位置的机会接近于零？
谢谢。
【问题讨论】：
标签： amazon-web-services amazon-redshift
在 Amazon Redshift 中优化查询的最佳方法是为 Distribution Key 和 Sort Key 使用适当的值。
Distribution Key (DISTKEY) 确定将哪些行放在哪个切片上（一个节点可以有多个切片）。通常，DISTKEY 应基于最常加入的列。
假设您有一个 Customer 表和一个 Invoice 表，并且这两个表都有一个 customer_id 列，用于连接这两个表。如果此字段用作两个表的 DISTKEY，则给定 customer_id 的两个表中的所有行都将存储在同一个切片中。这意味着节点不需要在切片或节点之间重新分配数据。这使 Amazon Redshift 能够并行处理数据。
当然，可能使用了许多 JOIN，因此并非总是如此。正如您所说，“不可预测的查询”并不总是得到优化。有关选择最佳 DISTKEY 的建议，请访问：Choose the best distribution style - Amazon Redshift
还有一些情况值得使用ALL 分布类型，这意味着表在所有节点上都复制。这避免了在节点之间发送数据，建议用于经常在查询中连接的小表。
还应该提到SORTKEY 同样重要。简单的规则是将 SORTKEY 设置为WHERE 语句中最常使用的列。这允许 Redshift 轻松“跳过”磁盘块，因为它为每个块存储了一个 Zone Map，指示存储在块中的最小值和最大值。 （一个块只包含一列的数据。）如果这一列是 SORTKEY，那么很容易识别哪些块可以跳过。由于从磁盘读取是一项非常耗时的操作，因此这也会加快查询速度，因为从磁盘读取的数据更少。
【讨论】：