从补丁 198 开始，Amazon Redshift 将不再支持创建新的 Python UDF。现有的 Python UDF 将继续正常运行至 2026 年 6 月 30 日。有关更多信息，请参阅[博客文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。
# 排序键
**注意**
我们建议您使用 `SORTKEY AUTO` 创建表。如果您这样做，则 Amazon Redshift 会使用自动表优化来选择排序键。有关更多信息，请参阅 [自动表优化](t_Creating_tables.md)。本节的其余部分提供了有关排序顺序的详细信息。
在创建表时，您可以将其一个或多个列定义为*排序键*。初次向空表中加载数据时，行以排序顺序存储在磁盘上。有关排序键列的信息会被传递给查询计划程序，后者借助该信息构建能够充分利用数据排序方式的计划。有关更多信息，请参阅 [CREATE TABLE](r_CREATE_TABLE_NEW.md)。有关创建排序键时最佳实践的信息，请参阅[选择最佳的排序键](c_best-practices-sort-key.md)。
排序可实现范围限制谓词的高效处理。Amazon Redshift 将列式数据存储在 1 MB 的磁盘数据块中。每个数据块的最小值和最大值作为元数据的一部分存储。如果查询使用范围限制谓词，则查询处理器可在表扫描期间借助该最小值和最大值快速跳过大量的数据块。例如，假设某张表存储着按日期排序的五年数据，且查询指定了一个月的日期范围。在这种情况下，您可以从扫描中最高消除 98% 的磁盘数据块。如果数据未排序，则该查询就不得不扫描更多（也可能是全部）的磁盘数据块。
您可以指定复合排序键或交错排序键。当查询谓词使用了*前缀*（有序排序键列的子集）时，复合排序键的效率更高。交错排序键为排序键中的每个列赋予相同的权重，因此，查询谓词可以使用构成该排序键的列的任意子集（可以是任意顺序）。
要了解排序键的选择对查询性能产生的影响，请使用 [EXPLAIN](r_EXPLAIN.md) 命令。有关更多信息，请参阅 [查询计划和执行工作流程](c-query-planning.md)。
要定义排序类型，请在您的 CREATE TABLE 或 CREATE TABLE AS 语句中使用 INTERLEAVED 或 COMPOUND 关键字。默认为 COMPOUND。如果使用 INSERT、UPDATE 或 DELETE 操作定期更新表，则建议使用 COMPOUND。INTERLEAVED 排序键可使用多达八个列。根据您的数据和集群大小，VACUUM REINDEX 所需的时间显著大于 VACUUM FULL 所需的时间，因为它需要执行额外的过程来分析交错排序键。对于交错表，排序和合并操作所花费的时间更长，因为与复合排序相比，交错排序可能有更多需要重新排列的行。
要查看某张表的排序键，请查询 [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md) 系统视图。
**Topics**
+ [多维数据布局排序](t_Sorting_mutidimensional-sort-key.md)
+ [复合排序键](t_Sorting_data-compound.md)
+ [交错排序键](t_Sorting_data-interleaved.md)
# 多维数据布局排序
多维数据布局排序键是一种基于工作负载中重复谓词的 AUTO 排序键。如果您的工作负载具有重复谓词，那么 Amazon Redshift 可以通过将满足重复谓词的数据行放在同一位置来提高表扫描性能。多维数据布局排序键不是按照严格的列顺序存储表数据，而是通过分析工作负载中出现的重复谓词来存储数据。在一个工作负载中可以找到多个重复谓词。根据您的工作负载，这种排序键可以提高许多谓词的性能。Amazon Redshift 会自动确定是否应将这种排序键方法用于使用 `AUTO` 排序键定义的表。
例如，假设您有一个按列顺序排列数据的表。可能需要检查许多数据块，以确定它们是否满足工作负载中的谓词。但是，如果数据是按谓词顺序存储在磁盘上的，那么为满足查询需要扫描的数据块就会减少。在这种情况下，使用多维数据布局排序键是有益的。
要查看查询是否使用了多维数据布局键，请查看 [SYS\$1QUERY\$1DETAIL](SYS_QUERY_DETAIL.md) 视图的 `step_attribute` 列。当值为 `multi-dimensional` 时，多维数据布局用于查询。
要防止 Amazon Redshift 使用多维数据布局排序键，请选择除 `SORTKEY AUTO` 之外的其他表排序键选项。有关 SORTKEY 选项的更多信息，请参阅 [CREATE TABLE](r_CREATE_TABLE_NEW.md)。
# 复合排序键
复合键由排序键定义中列出的所有列组成（顺序即为其排列顺序）。当查询的筛选条件应用了使用排序键前缀的条件（如筛选条件和联接）时，复合排序键最为有用。当查询只依赖于辅助排序列而不引用主列时，复合排序的性能优势会下降。COMPOUND 是默认的排序类型。
复合排序键可以加快联接、GROUP BY 和 ORDER BY 操作，以及使用 PARTITION BY 和 ORDER BY 的窗口函数。例如，当数据在联接列上分配和预先排序时，可以使用合并联接（通常快于哈希联接）。此外，复合排序键还有助于提高压缩率。
在您向已包含数据的排序表中添加行的同时，未排序区域也随之增长，这会对性能产生显著的影响。当表使用交错排序时，特别是当排序列包含单调递增数据（如日期或时间戳列）时，这种影响会更大。定期运行 VACUUM 操作，特别是在加载大量数据后，以重新排序和重新分析数据。有关更多信息，请参阅 [减少未排序区域的大小](vacuum-managing-vacuum-times.md#r_vacuum_diskspacereqs)。在执行 vacuum 操作以重新排序数据后，最好运行 ANALYZE 命令以更新查询计划程序的统计元数据。有关更多信息，请参阅 [分析表](t_Analyzing_tables.md)。
# 交错排序键
交错排序为排序键中的每个列或列的子集赋予相同的权重。如果多个查询使用不同的列作为筛选条件，则通常可以使用交错排序方式来提高这些查询的性能。当查询对辅助排序列使用限制性谓词时，与复合排序相比，交错排序可显著提高查询的性能。
**重要**
不要在具有单调递增属性的列（例如，身份列、日期或时间戳）上使用交错排序键。
您应将实施交错排序键获得的性能提升与增加的负载和 vacuum 次数进行权衡。
交错排序对于高选择性查询（在 WHERE 子句中对一个或多个排序键列进行筛选的查询，如 `select c_name from customer where c_region = 'ASIA'`）最为有效。交错排序的优势随着受限制排序列数量的增加而增大。
交错排序对于大型表更为有效。排序应用于每个切片。因此，当某张表大到足以使每个切片占用多个 1 MB 数据块时，交错排序最为有效。在这里，查询处理器可以使用限制性谓词跳过大部分数据块。要查看表使用的数据块数，请查询 [STV\$1BLOCKLIST](r_STV_BLOCKLIST.md) 系统视图。
对单一列进行排序时，如果该列的值拥有较长的共同前缀，则交错排序的性能要优于复合排序。如都以“http://www”打头的 URL。复合排序键使用前缀中有限数量的字符，因此会产生大量的重复键。交错排序为区域映射值使用了内部压缩方案，使它们能够更好地区分具有较长共同前缀的列值。
当将 Amazon Redshift 预置集群迁移到 Amazon Redshift Serverless 时，Redshift 同时将具有交错排序键和 DISTSTYLE KEY 的表转换为复合排序键。但是，只具有交错排序键的表保持不变。有关分配方式的更多信息，请参阅[使用数据分配方式](https://docs.aws.amazon.com//redshift/latest/dg/t_Distributing_data.html)。
**VACUUM REINDEX**
在您向已包含数据的排序表中不断添加行的过程中，性能会逐渐下降。复合排序和交错排序都会出现这种性能下降，但交错表受到的影响更大。VACUUM 可恢复排序顺序，但对于交错表，该操作可能需要花费更长的时间，因为合并新的交错数据可能涉及到修改每一个数据块。
初次加载表时，Amazon Redshift 会分析值在排序键列中的分配，并利用该信息来优化排序键列的交错操作。随着表的增大，排序键列中值的分配可能会发生变化或偏斜，日期或时间戳列的变化或偏斜更加明显。如果偏斜过大，则性能会受到影响。要重新分析排序键并恢复性能，请运行包含 REINDEX 关键字的 VACUUM 命令。对于交错表，由于它必须对数据进行额外的分析，因此，VACUUM REINDEX 需要花费比标准 VACUUM 操作还要长的时间。要查看有关键分配偏斜和上次重建索引时间的信息，请查询 [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) 系统视图。
有关如何确定运行 VACUUM 的频度和运行 VACUUM REINDEX 的时机的更多信息，请参阅[决定是否重建索引](vacuum-managing-vacuum-times.md#r_vacuum-decide-whether-to-reindex)。