为什么我的查询在 Amazon Redshift 维护后的运行时间更长？

简短描述

在版本升级期间，Amazon Redshift 会清除其查询缓存和编译缓存。升级后首次运行查询时，编译时间会更长。但是，随着 Amazon Redshift 重建其缓存，性能逐渐提高。

Amazon Redshift 不会更改所有维护时段操作的集群版本。要识别版本更改，请检查 SYS_QUERY_HISTORY 表中的 redshift_version 列。

有关 Amazon Redshift 中缓存类型的详细信息，请参阅结果缓存和编译后的代码。有关查询性能的详细信息，请参阅影响查询性能的因素。

解决方法

分析维护前后的查询性能

确定维护前后运行的查询。您可以使用查询监控控制台或 SYS_QUERY_HISTORY 系统视图。

要查找最近 20 个用户查询，请运行以下查询：

SELECT * FROM sys_query_history
WHERE user_id>1
ORDER BY start_time desc
limit 20;

在输出中，使用 user_query_hash 列将查询与相同查询文本进行比较。或者，使用 generic_query_hash 来比较查询文本相似但查询字面量不同的查询。

要查看过去 7 天内每次运行特定查询的时间，请运行以下查询：

SELECT * FROM sys_query_history
WHERE user_query_hash = 'ExampleText'
ORDER BY start_time desc;

**注意：**将 ExampleText 替换为查询哈希值。

在输出中，比较不同运行的 compile_time 值。您在维护后立即运行的查询的编译时间可能会更长。

要缩短编译时间，请安排关键查询在维护后运行，或者在非高峰时段预热关键查询。

**注意：**查询运行引擎为 Java 数据库连接 (JDBC) 和 Microsoft 开放式数据库连接 (ODBC) 连接协议编译不同的代码。如果您有两个使用不同协议的客户端，则每个客户端都会产生编译代码的首次开销。但是，使用相同协议的客户端共享缓存的代码。当您使用 JDBC 连接到集群并运行查询时，Amazon Redshift 仅为 JDBC 连接保存缓存。如果您在使用 ODBC 的客户端上运行相同的查询，则 Amazon Redshift 会为 ODBC 连接生成另一个缓存。

对问题进行故障排除

有时，当查询编译在维护前后显示出微小差异时，可能会出现无关的性能问题。使用查询和数据库监控控制台监控指标的异常峰值。比较编译时间以确定问题的根源。

如果您没有发现峰值但仍遇到问题，请创建支持案例。

相关信息

SVL_COMPILE