在 Amazon Redshift 中使用查询分析器简化查询性能诊断

关键要点

Amazon Redshift 提供了查询分析器功能，帮助用户直观分析查询性能。查询分析器能有效识别长时间运行的查询问题，提供执行计划和性能数据。本文介绍了使用查询分析器排查两种常见查询性能问题的步骤。

Amazon Redshift 是一个快速、可扩展、安全且完全托管的云数据仓库，能够让用户大规模分析数据。Amazon Redshift Serverless 允许用户在无需进行通常配置的情况下访问和分析数据，自动配置资源，并智能地扩展数据仓库容量，以提供快速性能，无论在高负载还是不可预测的工作负载下。

为了帮助用户监控其管理的集群和数据库的健康状况，Amazon Redshift 提供了两类性能指标：

Amazon CloudWatch 指标 用于监控集群或无服务器架构的物理方面，例如资源使用率、延迟和吞吐量。查询和加载性能数据 帮助用户监控数据库活动，检查和诊断查询性能问题。

为此，Amazon Redshift 引入了一项新功能查询分析器。该工具通过图形化界面帮助用户分析查询的组成部分及其性能。查询分析器提供了查询运行顺序、执行计划和各种统计数据的可视化表示，使用户更容易理解和故障排除查询。

机场翻墙

在本文中，我们将介绍两个常见的查询性能问题及其排查步骤。

概述

对于 Amazon Redshift Serverless，查询分析器可以通过访问 Serverless 控制台进行访问。选择 查询和数据库监控，选择一个查询，然后导航至 查询计划 标签。如果有可用的查询计划，将会看到子查询的列表。选择一个查询以在查询分析器中查看。

对于 Amazon Redshift 提供的集群，可以通过访问提供的集群仪表板来访问查询分析器。选择 查询和加载，然后选择一个查询。导航至 查询计划 标签，就可以观察到可用的子查询列表。

前提条件

您可以使用以下示例 AWS 身份和访问管理 IAM策略，配置 IAM 用户或角色，使其最低权限以访问 AWS 控制台中的查询分析器。如用户或角色已对 Redshift 提供集群仪表板中的 查询和加载 段或 Redshift Serverless 仪表板中的 查询和数据库监控 段有访问权限，则无需额外权限：

json{ Version 20121017 Statement [ { Effect Allow Action [ redshiftDescribeClusters redshiftserverlessListNamespaces redshiftserverlessListWorkgroups redshiftdataExecuteStatement redshiftdataDescribeStatement redshiftdataGetStatementResult ] Resource [ arnawsredshiftserverlessltyournamespacegt arnawsredshiftserverlessltyourworkgroupnamegt arnawsredshiftltyourclusternamegt ] } ]}

您可以选择在已有的 Amazon Redshift 数据仓库和查询中使用查询分析器。不过，如果想在现有的 Amazon Redshift 数据仓库中实施此演示，请下载 Redshift 查询编辑器 v2 笔记本， Redshift 查询分析器演示，并参考本文后续的 数据加载 部分。您必须使用数据库凭据连接集群，并授予 sysoperator 或 sysmonitor 角色给相应的数据库用户，以查看用户执行的查询。

数据加载

Amazon Redshift 查询编辑器 v2 提供了示例数据，可加载到示例数据库及其对应的架构中。要通过示例数据测试查询分析器，请加载 tpcds 示例数据并运行查询。

启动 Redshift 查询编辑器 v2，展开数据库 sampledatadev 以加载 tpcds 示例数据。选择与 tpcds 相关联的图标。查询编辑器 v2 将数据加载到数据库 sampledatadev 中的 tpcds 架构中。

以下截图展示了这些步骤。

通过运行以下示例查询来验证数据，如下截图所示。

sqlselect count() from sampledatadevtpcdscustomer

用例

本文中，我们描述了两个关于查询性能的常见用例，以及如何使用查询分析器来排查性能问题：

嵌套循环连接 这种连接类型是所有可能的连接类型中最慢的。嵌套循环连接是没有连接条件的交叉连接，导致两个表之间的笛卡尔积。不理想的数据分布 如果数据分布不理想，您可能会在连接两个大表时注意到大量的数据广播或重新分配。

用例 1：嵌套循环连接

要使用查询分析器排查嵌套循环连接的性能问题，请按照以下步骤操作：

将先前在 前提条件 部分下载的笔记本导入到 Redshift 查询编辑器 v2。

在查询编辑器 v2 中，将数据库上下文设置为 sampledatadev，如下截图所示。

从演示笔记本运行 cell #3，以诊断与嵌套循环连接相关的查询性能问题。

查询的运行时间约为 12 秒，如查询编辑器 v2 的结果面板所示。

运行 cell #5 从 SYSQUERYHISTORY 系统视图中捕获 查询 ID，根据您在前一步骤中设置的查询标签进行过滤。

在 Amazon Redshift 控制台中，导航窗格选择 查询和加载，选择原始执行查询的集群名称，如下图所示。

这将打开新的查询分析器。在 查询历史 部分选择 连接到数据库。成功连接后，您会看到状态显示为 已连接，并显示查询历史，如下图所示。

您可以通过 查询 ID 或 进程 ID 找到您的查询。输入在前面步骤中捕获的查询 ID 以过滤长时间运行的查询，选择对应的查询 ID，如下图所示。

在 查询计划 部分，选择 子查询 1，如图所示。如果有多个子查询，则需要检查每一个子查询的性能问题。这将以树状视图打开查询计划，并在侧边面板显示附加的度量指标。您可以快速分析查询流、片段和步骤。有关流、片段和步骤的更多信息，请参阅 查询计划和执行工作流 在 Amazon Redshift 数据库开发者指南中。

开启 查看流，在 流 侧边面板中调查并识别哪个流的执行时间最长。在这种情况下，流 ID 5 是查询耗时最多的部分，如下图所示。

在 流 侧边面板中，在 ID 下选择 5，以进一步分析流。流 5 显示为 嵌套循环 步骤，如下图所示。

选择 嵌套循环 步骤以进一步分析。侧边面板将显示步骤详情及嵌套循环连接的附加指标。

从 步骤详情 嵌套循环，我们可以检查 输入行 与 输出行 相比的情况，如下图所示。在这种情况下，由于与 Storereturns 表的交叉连接，287514 的输入行膨胀到 950233770 行，从而导致查询变慢。

通过在 storesales 和 storereturns 之间引入连接条件修复查询。运行查询编辑器 v2 演示笔记本中的 cell #7。重新编写的查询运行仅需 307 毫秒。

用例 2：不理想的数据分布

为了演示数据分布不理想，运行查询编辑器 v2 演示笔记本的 cell #10，将 websales 和 webreturns 表的分布样式更改为 均匀。

运行 cell #12。如查询编辑器的运行时间所示，查询运行时间为 409 毫秒。

按照 用例 1 中的步骤 310 定位 queryid，并打开查询分析器查看前述查询。

在前述查询的查询分析器页面，开启 查看流。在 流 侧边面板中，调查并识别哪个流的执行时间最长。在这种情况下，流 ID 6 是查询耗时最多的部分，如下图所示。

在 ID 下，选择 6 以进行进一步分析。

流 6 显示一个哈希连接步骤，其中涉及对两个均重新分配的表进行哈希连接。这可以从 解释计划节点信息 中的 Hash Right Join DSDISTBOTH 来推测。通常，这些重新分配发生是因为表未在其分布键上连接，或其没有正确的分布样式。对于大型表，这些重新分配可能会导致显著的性能下降，因此识别和修复明细以优化查询性能是重要的。

通过在参与连接的表 websales 和 webreturns 上选择适当的分布键来修复此不理想的数据分布模式。要更改分布样式，请运行演示笔记本的 cell #14 更改表命令。

在前述命令执行完成后，运行 cell #16 重新执行选择查询。更新分布样式为分布键后，查询在查询编辑器中完成仅需 244 毫秒。

在查询分析器视图中，开启 查看流，注意到 流 ID 5 当前耗时最多，完成仅需 8 毫秒，相比上一步增加到 13 毫秒的耗时明显减少。

在 流 侧边面板中，在 ID 下选择 5 进行更深入的剖析，然后选择 哈希连接。如以下截图所示，在将 websales 和 webreturns 表的分布样式更改为分布键后，查询运行时不需要重新分配，导致优化性能的实现。

注意事项

使用查询分析器时，请考虑以下细节：

查询分析器显示的信息来自 SYSQUERYHISTORY、SYSQUERYEXPLAIN、SYSQUERYDETAIL 和 SYSCHILDQUERYTEXT 视图。查询分析器仅显示对近期运行在数据库上的查询的信息。如果查询使用已预填充的结果缓存完整，查询分析器将没有关于它的信息，因为