我正在尝试将非常大量的数据加载到一个表格的红移中，这个表格在加载后真的太昂贵了。为了避免必须对此表进行真空处理，我使用COPY命令从大量预先排序的CSV文件中加载数据。我加载的文件是根据表中定义的排序键预先排序的。
然而，在加载前两个文件后，我发现redshift报告该表为~50％未排序。我已经验证了文件的数据排序顺序正确。为什么redshift不能识别已经排序的新传入数据？ 我是否必须做一些特别的事情让复制命令知道这个新数据已经按正确的排序顺序了？
我正在使用SVV_TABLE_INFO表来确定排序百分比（使用未排序的字段）。排序键是三个不同字段（平面，x，y）的复合键。
Redshift支持官方回答：
这是我们正式说的： http://docs.aws.amazon.com/redshift/latest/dg/vacuum-load-in-sort-key-order.html
当您的表定义了排序键时，表格分为2 区域：
- 已排序，
- 未排序
只要以排序的键顺序加载数据，即使数据是 在未排序的区域中，它仍处于排序键顺序中，因此没有 需要VACUUM来确保数据的排序。仍然需要VACUUM 将数据从未排序区域移动到排序区域， 然而，由于未分类区域中的数据，这一点不那么重要 已经排序。
答案 0 :(得分：1)
在Amazon Redshift表中存储排序数据会对以下几个方面产生影响：
ORDER BY时数据的显示方式ORDER BY时数据的排序速度（例如，如果排序主要是预先排序，则排序速度更快）虽然您可能希望选择提高排序速度的SORTKEY（例如Change order of sortkey to descending），但SORTKEY的主要好处是通过最小化磁盘访问来使查询运行得更快使用区域地图。
我承认，似乎没有关于Zone Maps如何工作的大量文档，所以我会在这里尝试解释它。
Amazon Redshift将数据存储在1MB块的磁盘上。每个块包含与一个表的一列相关的数据，来自该列的数据可以占用多个块。块可以被压缩，因此它们通常包含超过1MB的数据。
磁盘上的每个块都有一个关联的区域映射，用于标识该块中存储的列的最小值和最大值。这使Redshift能够跳过不包含相关数据的块。例如，如果SORTKEY是时间戳并且查询具有将数据限制为特定日期的WHERE子句，则Redshift可以跳过所需日期不在该块内的任何块。< / p>
一旦Redshift找到具有所需数据的块，它就会将这些块加载到内存中，然后在加载的数据中执行查询。
当只需从磁盘加载尽可能少的块时，查询将在Redshift中运行最快。因此，最好使用通常与SORTKEY子句匹配的WHERE，例如数据通常受日期范围限制的时间戳。有时值得将SORTKEY设置为与DISTKEY相同的列，即使它们用于不同目的。
可以通过STV_BLOCKLIST虚拟系统表查看区域地图。该表中的每一行包括：
我怀疑在表被抽真空后设置了Sorted标志。但是，表格不一定需要抽真空。例如，如果数据始终按时间戳顺序附加，则数据已经在磁盘上排序，从而使Zone Maps能够最有效地工作。
您提到您的SORTKEY是＆＃34;使用3个字段＆＃34;的复合键。这可能不是最好的SORTKEY。可能值得针对具有不同SORTKEY的表运行一些计时测试，以确定复合SORTKEY是否优于使用单个SORTKEY。如果WHERE子句中经常使用所有3个字段，则复合键可能表现最佳。