从补丁 198 开始，Amazon Redshift 将不再支持创建新的 Python UDF。现有的 Python UDF 将继续正常运行至 2026 年 6 月 30 日。有关更多信息，请参阅[博客文章](https://www.amazonaws.cn/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。
# Amazon Redshift 性能
本主题介绍可提高性能的 Amazon Redshift 组件。了解这些组件将有助于您使用 Amazon Redshift 优化性能并解决性能不佳的问题。
Amazon Redshift 通过使用这些性能功能来实现极快的查询运行。
**Topics**
+ [大规模并行处理](#massively-parallel-processing)
+ [列式数据存储](#columnar-data-storage)
+ [数据压缩](#data-compression)
+ [查询优化程序](#query-optimizer)
+ [结果缓存](#result-caching)
+ [编译后的代码](#compiled-code)
## 大规模并行处理
大规模并行处理 (MPP) 支持对大量数据快速运行最复杂的查询。多个计算节点处理所有查询处理以获得最终结果聚合，运行相同的编译后查询的每个节点的每个核心在整个数据的各个部分进行分段。
Amazon Redshift 将表行分配给计算节点，以便能并行处理数据。通过为每个表选择相应的分配键，可以优化数据分配以均衡工作负载，并最大程度地减少节点间的数据移动。有关更多信息，请参阅 [选择最佳的分配方式](c_best-practices-best-dist-key.md)。
加载平面文件中的数据时将利用并行处理，方式是跨多个节点分配工作负载，同时从多个文件进行读取。有关如何将数据加载到表的更多信息，请参阅[Amazon Redshift 加载数据的最佳实践](c_loading-data-best-practices.md)。
## 列式数据存储
数据库表的列式存储大大降低了总体磁盘 I/O 要求，它是优化分析查询性能的一个重要因素。有关更多信息，请参阅 [列式存储](c_columnar_storage_disk_mem_mgmnt.md)。
在适当地对列进行排序时，查询处理器能够快速筛选出大型数据块子集。有关更多信息，请参阅 [选择最佳的排序键](c_best-practices-sort-key.md)。
## 数据压缩
数据压缩将降低存储要求，从而减少磁盘 I/O 来提高查询性能。在运行查询时，压缩的数据将读入内存，然后在查询运行期间解压缩。将少量数据加载到内存中使 Amazon Redshift 能够分配更多内存来分析数据。由于列式存储将按顺序存储类似数据，因此 Amazon Redshift 能够应用与列式数据类型关联的自适应压缩编码。对表列启用数据压缩的最佳方式是，允许 Amazon Redshift 在您将表与数据一起加载时应用最优压缩编码。要了解有关使用自动数据压缩的更多信息，请参阅[使用自动压缩加载表](c_Loading_tables_auto_compress.md)。
## 查询优化程序
Amazon Redshift 查询运行引擎集成了 MPP 感知的查询优化程序并采用了面向列式的数据存储。Amazon Redshift 查询优化程序实施大量增强和扩展以便处理通常包含多表联接、子查询和聚合的复杂的分析查询。要了解有关优化查询的更多信息，请参阅[查询性能优化](c-optimizing-query-performance.md)。
## 结果缓存
为了缩短查询运行时间并提高系统性能，Amazon Redshift 在领导节点的内存中缓存特定查询类型的结果。当用户提交查询时，Amazon Redshift 会在结果缓存中检查是否有查询结果的有效缓存副本。如果在结果缓存中找到匹配项，Amazon Redshift 会使用缓存的结果而不执行查询。结果缓存对用户透明。
默认情况下，结果缓存处于打开状态。要为当前会话禁用结果缓存，请将 [enable\_result\_cache\_for\_session](r_enable_result_cache_for_session.md) 参数设置为 `off`。
在满足以下所有条件时，Amazon Redshift 将为新查询使用缓存的结果：
+ 提交查询的用户具有查询中所用对象的访问权限。
+ 查询中的表或视图未更改。
+ 查询不使用必须在每次运行时求值的函数，例如 GETDATE。
+ 该查询不引用 Amazon Redshift Spectrum 外部表。
+ 可能影响查询结果的配置参数未更改。
+ 查询的语法与缓存的查询相符。
为了最大限度地提升缓存有效性和资源的使用效率，Amazon Redshift 不缓存一些非常大的查询结果集。Amazon Redshift 会根据多个因素确定是否缓存查询结果。这些因素包括缓存中的条目数以及 Amazon Redshift 集群的实例类型。
要确定查询是否使用了结果缓存，请查询 [SVL\_QLOG](r_SVL_QLOG.md) 系统视图。如果查询使用了结果缓存，source\_query 列会返回源查询的查询 ID。如果未使用结果缓存，则 source\_query 列值为 NULL。
以下示例说明了由 userid 104 和 userid 102 提交的查询使用了来自 userid 100 运行的查询的结果缓存。
```
select userid, query, elapsed, source_query from svl_qlog
where userid > 1
order by query desc;
userid | query | elapsed | source_query
-------+--------+----------+-------------
104 | 629035 | 27 | 628919
104 | 629034 | 60 | 628900
104 | 629033 | 23 | 628891
102 | 629017 | 1229393 |
102 | 628942 | 28 | 628919
102 | 628941 | 57 | 628900
102 | 628940 | 26 | 628891
100 | 628919 | 84295686 |
100 | 628900 | 87015637 |
100 | 628891 | 58808694 |
```
## 编译后的代码
代码编译：Amazon Redshift 为每个查询执行计划生成和编译优化的代码。编译代码执行更快，因为它消除了使用解释器的开销。为了最大限度地减少新查询的延迟，同时保留编译代码的性能优势，Amazon Redshift 使用一种称为合成的技术。合成可生成预先存在的逻辑的轻量级排列以便立即处理新查询，同时在后台编译高度优化的查询专用代码。这会将编译从查询执行的关键路径中移除，因此，新查询可以更快地启动并提供与后续运行一致的性能。
Amazon Redshift 还使用无服务器编译服务将查询编译扩展到 Amazon Redshift 集群的计算资源之外。编译的代码段既本地缓存于集群上，也缓存于一个几乎无限的远程缓存中，该缓存在集群重启后持续存在。相同查询的后续执行可以更快地运行，因为它们可以跳过编译阶段。通过使用可扩展的编译服务，Amazon Redshift 并行编译代码，以提供始终如一的快速性能。