从补丁 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/)。
# Amazon Redshift 中的行为更改
随着 Amazon Redshift 不断发展和改进，为了增强性能、提高安全性和改善用户体验，我们引入了一些行为更改。此页面包含全面的资源，让您可以随时了解这些关键更新，采取必要措施，并避免对工作负载造成中断。
## 即将发生的行为更改
以下描述了即将发生的行为更改。
**Topics**
+ [标量 Python UDF 将在 2026 年 6 月 30 日之后终止支持](#python-udf-jun2026)
+ [2026 年 2 月 27 日之后的实体化视图（MV）自动 REFRESH 行为更改](#autorefresh-feb272026)
+ [2026 年 2 月 16 日之后，Amazon Redshift 将不支持通过数据共享访问使用者信息的函数](#datasharing-feb2026)
+ [传输层安全性协议（TLS）最低版本变更自 2026 年 1 月 31 日起生效](#tls-changes-jan2026)
+ [2025 年 10 月 30 日之后，Amazon Redshift 将不支持创建新的标量 Python UDF](#python-udf-oct2025)
### 标量 Python UDF 将在 2026 年 6 月 30 日之后终止支持
Amazon Redshift 将在 2026 年 6 月 30 日之后终止对 Python UDF 的支持。作为替代方案，我们建议您使用 Lambda UDF。
与 Python UDF 相比，Lambda UDF 具有以下优点：
+ Lambda UDF 可以从 UDF 逻辑内部连接到外部服务和 API。
+ Lambda UDF 使用 Lambda 计算资源。计算密集型或内存密集型 Lambda UDF 不会影响 Amazon Redshift 的查询性能或资源并发性。
+ Lambda UDF 支持运行 Python 代码。Lambda UDF 支持多个 Python 运行时，具体取决于特定的使用案例。有关更多信息，请参阅《AWS Lambda 开发人员指南》**中的[使用 Python 构建](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html)。
+ 您可以将自定义代码执行隔离在单独的服务边界中。这可简化维护、监控、预算制定和权限管理。
有关创建和使用 Lambda UDF 的信息，请参阅《Amazon Redshift 数据库开发人员指南》**中的[标量 Lambda UDF](https://docs.aws.amazon.com/redshift/latest/dg/udf-creating-a-lambda-sql-udf)。有关将现有 Python UDF 转换为 Lambda UDF 的信息，请参阅[博客文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。
### 2026 年 2 月 27 日之后的实体化视图（MV）自动 REFRESH 行为更改
从 2026 年 2 月 27 日起，Amazon Redshift 实体化视图的自动 REFRESH 查询将作为用户查询而不是后台自主进程执行。因此，自动 REFRESH 查询现在的运行优先级与其它用户查询相同。
与之前的行为相比，此更改提高了启用自动 REFRESH 功能的实体化视图的新鲜度，有助于它们更及时地了解对基表的最新更改。
注意：MV 自动 REFRESH 行为更改功能仅适用于补丁版本 P198 及更高版本的当前跟踪版本上的 Amazon Redshift 预置集群。它目前在无服务器上处于禁用状态。
### 2026 年 2 月 16 日之后，Amazon Redshift 将不支持通过数据共享访问使用者信息的函数
从 2026 年 2 月 16 日起，Amazon Redshift 将不再支持使用 `user_is_member_of` 以及通过数据共享访问使用者用户、角色或组信息的相关函数。
### 传输层安全性协议（TLS）最低版本变更自 2026 年 1 月 31 日起生效
自 2026 年 1 月 31 日起，Amazon Redshift 将强制使用最低的传输层安全性协议（TLS）版本 1.2。使用 TLS 版本 1.0 或 1.1 的传入连接将遭到拒绝。这同时适用于 Amazon Redshift 预置集群和无服务器工作组。未使用 TLS 的 Amazon Redshift 数据仓库将不受此变更的影响。
如果您使用 TLS 版本 1.0 或 1.1 连接到 Amazon Redshift，此更新可能会影响您。
要验证您当前使用的 TLS 版本，您可以：
对于 Amazon Redshift 预置：检查 STL\$1CONNECTION\$1LOG 系统表中的 sslversion 列 [1]。
对于 Amazon Redshift Serverless 工作组：检查 SYS\$1CONNECTION\$1LOG 系统表中的 ssl\$1version 列 [2]。
要在此更改后保持对 Amazon Redshift 数据仓库的不间断访问，请按照以下所列步骤操作：
1. 更新您的客户端以支持 TLS 1.2 或更高版本
1. 安装支持 TLS 1.2\$1 的最新驱动程序版本
如果可能，我们建议使用最新版本的 Amazon Redshift 驱动程序 [3]。
[1] [https://docs.aws.amazon.com/redshift/latest/dg/r\$1STL\$1CONNECTION\$1LOG.html](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_CONNECTION_LOG.html)
[2] [https://docs.aws.amazon.com/redshift/latest/dg/SYS\$1CONNECTION\$1LOG.html](https://docs.aws.amazon.com/redshift/latest/dg/SYS_CONNECTION_LOG.html)
[3] [https://docs.aws.amazon.com/redshift/latest/mgmt/configuring-connections.html](https://docs.aws.amazon.com/redshift/latest/mgmt/configuring-connections.html)
### 2025 年 10 月 30 日之后，Amazon Redshift 将不支持创建新的标量 Python UDF
2025 年 10 月 30 日之后，Amazon Redshift 将不再支持创建新的 Python UDF。现有的 Python UDF 将继续正常运行。我们强烈建议您在该日期之前将现有的 Python UDF 迁移至 Lambda UDF。
与 Python UDF 相比，Lambda UDF 具有以下优点：
+ Lambda UDF 可以从 UDF 逻辑内部连接到外部服务和 API。
+ Lambda UDF 使用 Lambda 计算资源。计算密集型或内存密集型 Lambda UDF 不会影响 Amazon Redshift 的查询性能或资源并发性。
+ Lambda UDF 支持运行 Python 代码。Lambda UDF 支持多个 Python 运行时，具体取决于特定的使用案例。有关更多信息，请参阅《AWS Lambda 开发人员指南》**中的[使用 Python 构建](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html)。
+ 您可以将自定义代码执行隔离在单独的服务边界中。这可简化维护、监控、预算制定和权限管理。
有关创建和使用 Lambda UDF 的信息，请参阅《Amazon Redshift 数据库开发人员指南》**中的[标量 Lambda UDF](https://docs.aws.amazon.com/redshift/latest/dg/udf-creating-a-lambda-sql-udf)。有关将现有 Python UDF 转换为 Lambda UDF 的信息，请参阅[博客文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。
## 最近的行为更改
**Topics**
+ [2025 年 8 月 26 日之后，Amazon Redshift 使用最新的 IANA 时区数据库](#timezone-changes-aug2025)
+ [Amazon Redshift Serverless RPU 更改将于 2025 年 8 月 15 日之后生效](#serverless-rpu-aug2025)
+ [数据库审计日志记录更改在 2025 年 8 月 10 日之后生效](#audit-logging-aug2025)
+ [无服务器工作组的虚拟私有云端点更改将于 2025 年 6 月 27 日之后生效](#VPCE-jun2025)
+ [查询监控更改于 2025 年 5 月 2 日之后生效](#query-monitoring-changes-may2025)
+ [在 2025 年 1 月 10 日之后生效的安全更改](#security-changes-jan2025)
### 2025 年 8 月 26 日之后，Amazon Redshift 使用最新的 IANA 时区数据库
从 2025 年 8 月 26 日起，Amazon Redshift 通过采用最新的 IANA 时区数据库补丁来计算时区。此更改会更改某些时区和时段的日期和时间转换的运作方式。此更新会影响显式时区转换，例如使用 [CONVERT\$1TIMEZONE](https://docs.aws.amazon.com/redshift/latest/dg/CONVERT_TIMEZONE.html) 函数或 [TIMEZONE](https://docs.aws.amazon.com/redshift/latest/dg/r_TIMEZONE.html) 和 [AT TIME ZONE](https://docs.aws.amazon.com/redshift/latest/dg/r_AT_TIME_ZONE.html) 命令执行的转换，以及在类型强制转换操作期间发生的隐式转换，特别是 [TIMESTAMP](https://docs.aws.amazon.com/redshift/latest/dg/r_Datetime_types.html#r_Datetime_types-timestamp) 和 [TIMESTAMPTZ](https://docs.aws.amazon.com/redshift/latest/dg/r_Datetime_types.html#r_Datetime_types-timestamptz) 格式之间的转换。
以下是时区和时段组合的更新列表：
+ 现在，在 2038 年后，时区可以正确地遵守夏令时（DST）。以前，在 2038 年后，没有时区遵循夏令时。
+ 对于 `America/Toronto` 时区以及与之关联的时区，在 1947-1950 年，夏令时在当地时间凌晨 2 点而不是午夜进行切换。
+ Amazon Redshift 现在可以正确反映在所有时区标准化之前时段的本地平均时间（LMT）。这个时段是特定于时区的，大多数时区在 19 世纪中叶之前都转向了标准化。
+ `EET`、`CET`、`WET` 和 `MET` 现在被视为正常时区而不是缩写。
+ Amazon Redshift 中不再存在以下时区名称：
+ `Asia/Riyadh87`
+ `Asia/Riyadh88`
+ `Asia/Riyadh89`
+ `Mideast/Riyadh87`
+ `Mideast/Riyadh88`
+ `Mideast/Riyadh89`
+ `US/Pacific-New`
有关 IANA 时区数据库的更多信息，请参阅 IANA 时区数据库网站上的 [Time Zone Database](https://www.iana.org/time-zones)。
### Amazon Redshift Serverless RPU 更改将于 2025 年 8 月 15 日之后生效
从 2025 年 8 月 15 日起，Amazon Redshift Serverless 基本 Redshift 处理器（RPU）的 AWS 账户配额为 3200 个 RPU 或前六个月最大累计基本 RPU 的 1.5 倍（以较大值为准）。
### 数据库审计日志记录更改在 2025 年 8 月 10 日之后生效
从 2025 年 8 月 10 日起，Amazon Redshift 将对数据库审计日志记录进行更改，这需要您采取行动。Amazon Redshift 会将有关数据库中连接和用户活动的信息记录到 Amazon S3 存储桶和 CloudWatch。2025 年 8 月 10 日之后，对于具有用于指定 Redshift IAM USER 的存储桶策略的 Amazon S3 存储桶，Amazon Redshift 将停止数据库审计日志记录。我们建议更新您的策略，以便在 S3 存储桶策略中改用 Redshift SERVICE-PRINCIPAL 来实现审计日志记录。有关审计日志记录的信息，请参阅 [Amazon Redshift 审计日志记录的存储桶权限](db-auditing.md#db-auditing-bucket-permissions)。
为避免任何日志记录中断，请在 2025 年 8 月 10 日之前查看并更新您的 S3 存储桶策略，以便向关联区域中的 Redshift 服务主体授予访问权限。有关数据库审计日志记录的信息，请参阅 [Amazon S3 中的日志文件](db-auditing.md#db-auditing-manage-log-files)。
如有疑问或疑虑，请通过以下链接联系 AWS 支持人员：[AWS Support](https://aws.amazon.com/support)。
### 无服务器工作组的虚拟私有云端点更改将于 2025 年 6 月 27 日之后生效
从 2025 年 6 月 27 日起，Amazon Redshift 更改虚拟私有云端点（VPCE）对无服务器工作组的支持。在此日期之前，Amazon Redshift 在工作组创建期间将端点部署到单个可用区（AZ），并随着时间推移将 VPCE 支持扩展到多达三个可用区。在此日期之后，Amazon Redshift 将在工作组创建期间指定的多达三个可用区中部署 VPCE。
有关更多信息，请参阅 [使用 Amazon Redshift Serverless 时的注意事项](serverless-usage-considerations.md)。
如有疑问或疑虑，请通过以下链接联系 AWS 支持人员：[AWS Support](https://aws.amazon.com/support)。
**Topics**
+ [2025 年 8 月 26 日之后，Amazon Redshift 使用最新的 IANA 时区数据库](#timezone-changes-aug2025)
+ [Amazon Redshift Serverless RPU 更改将于 2025 年 8 月 15 日之后生效](#serverless-rpu-aug2025)
+ [数据库审计日志记录更改在 2025 年 8 月 10 日之后生效](#audit-logging-aug2025)
+ [无服务器工作组的虚拟私有云端点更改将于 2025 年 6 月 27 日之后生效](#VPCE-jun2025)
+ [查询监控更改于 2025 年 5 月 2 日之后生效](#query-monitoring-changes-may2025)
+ [在 2025 年 1 月 10 日之后生效的安全更改](#security-changes-jan2025)
### 查询监控更改于 2025 年 5 月 2 日之后生效
自 2025 年 5 月 2 日起，我们将不再为现有和新创建的 Redshift Serverless 工作组提供**查询限制**选项卡中的查询 CPU 时间 (`max_query_cpu_time`) 和查询 CPU 使用率 (`max_query_cpu_percentage`) 指标。在此日期之后，我们将自动移除所有 Redshift Serverless 工作组中基于这些指标的所有查询限制。
查询限制旨在捕获失控的查询。但是，在查询的生命周期中，查询 CPU 时间 (`max_query_cpu_time`) 和查询 CPU 使用率 (`max_query_cpu_percentage`) 可能会有所不同，因此不是用于捕获失控查询的持续有效的方法。要捕获失控的查询，我们建议您利用可提供一致且切实可行的信息的查询监控指标。一些示例包括：
+ **查询执行时间** (`max_query_execution_time`)：确保查询在预期的时间范围内完成。
+ **返回行数** (`max_scan_row_count`)：监控正在处理的数据的规模。
+ **查询队列时间** (`max_query_queue_time`)：识别需要花费时间排队的查询。
有关支持的指标的完整列表，请参阅[查询 Amazon Redshift Serverless 的监控指标](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-query-monitoring-rules.html#cm-c-wlm-query-monitoring-metrics-serverless)。
### 在 2025 年 1 月 10 日之后生效的安全更改
安全性一直是 Amazon Web Services（AWS）的重中之重。为此，我们通过引入增强的安全默认值来进一步加强 Amazon Redshift 环境的安全状况，这些默认值有助于您在无需额外设置的情况下遵守数据安全的最佳实践，并降低潜在错误配置的风险。为避免任何潜在的中断，请在生效日期之前查看预置集群和无服务器工作组的创建配置、脚本和工具，以进行必要的更改，使其与新的默认设置保持一致。
#### 默认情况下禁用公共访问权限
2025 年 1 月 10 日之后，默认情况下，对于所有新创建的预置集群以及从快照还原的集群禁用[公共可访问性](rs-security-group-public-private.md)。在此版本中，默认情况下，只允许从同一虚拟私有云（VPC）内的客户端应用程序连接到集群。要从其它 VPC 中的应用程序访问数据仓库，请配置[跨 VPC](managing-cluster-cross-vpc.md) 访问。此更改将反映在 `CreateCluster` 和 `RestoreFromClusterSnapshot` API 操作以及相应的 SDK 和 AWS CLI 命令中。如果您通过 Amazon Redshift 控制台创建预置集群，则默认情况下，该集群已禁用公共访问权限。
如果您仍然需要公共访问权限，将需要在运行 `CreateCluster` 或 `RestoreFromClusterSnapshot` API 操作时覆盖默认值并将 `PubliclyAccessible` 参数设置为 true。对于可公共访问的集群，建议您必须使用安全组或网络访问控制列表（ACL）来限制访问权限。有关更多信息，请参阅[VPC 安全组](managing-vpc-security-groups.md)和[为 Amazon Redshift 集群或 Amazon Redshift Serverless 工作组配置安全组通信设置](rs-security-group-public-private.md)。
#### 默认加密
2025 年 1 月 10 日之后，Amazon Redshift 将通过启用加密来作为所有新创建的 Amazon Redshift 预置集群的默认设置，进一步增强数据和集群的安全性。这不适用于从快照还原的集群。
进行此更改后，当使用 AWS 管理控制台、AWS CLI 或 API 创建预置集群而不指定 KMS 密钥时，解密集群的功能将不再可用。集群将自动使用 AWS 拥有的密钥进行加密。
如果您使用自动脚本创建未加密的集群，或利用与未加密集群的数据共享，则此更新可能会对您产生影响。为确保无缝过渡，请更新用于创建未加密集群的脚本。此外，如果您定期创建新的未加密使用者集群并将其用于数据共享，请检查您的配置以确保生产者和使用者集群都经过加密，从而防止中断数据共享活动。有关更多信息，请参阅 [Amazon Redshift 数据库加密](working-with-db-encryption.md)。
#### 强制执行 SSL 连接
2025 年 1 月 10 日之后，Amazon Redshift 将默认对连接到新创建的预置和还原集群的客户端强制执行 SSL 连接。此默认更改也将适用于无服务器工作组。
通过此更改，将为所有新创建或还原的集群引入一个名为 `default.redshift-2.0` 的新默认参数组，而 `require_ssl` 参数默认设置为 `true`。在没有指定的参数组的情况下创建的任何新集群都将自动利用 `default.redshift-2.0` 参数组。通过 Amazon Redshift 控制台创建集群时，将自动选择新的 `default.redshift-2.0` 参数组。此更改还将反映在 `CreateCluster` 和 `RestoreFromClusterSnapshot` API 操作以及相应的 SDK 和 AWS CLI 命令中。如果您使用现有或自定义参数组，Amazon Redshift 将继续使用在参数组中指定的 `require_ssl` 值。您可以根据需要，继续选择更改自定义参数组中的 `require_ssl` 值。
对于 Amazon Redshift Serverless 用户，`config-parameters` 中的默认值 `require_ssl` 将更改为 `true`。任何创建将 `require_ssl` 设置为 `false` 的新工作组的请求都将被拒绝。创建工作组后，您可以将 `require_ssl` 值更改为 `false`。有关更多信息，请参阅 [配置连接的安全选项](connecting-ssl-support.md)。
请注意，如果您的特定用例需要，您仍然可以修改集群或工作组设置以更改默认行为。