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

关键要点

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

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

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

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

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

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

概述

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

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

前提条件

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

`json { "Version": "2012-10-17", "Statement": ，并参考本文后续的 数据加载 部分。

• 您必须使用数据库凭据连接集群，并 sys:operator 或 sys:monitor 角色给相应的数据库用户，以查看用户执行的查询。

数据加载

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

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

以下截图展示了这些步骤。
![Load删除)

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

sql select count(*) from sample_data_dev.tpcds.customer;

![Verify删除)

用例

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

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

用例 1：嵌套循环连接

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

1. 将先前在 前提条件 部分下载的笔记本导入到 Redshift 查询编辑器 v2。
2. 在查询编辑器 v2 中，将数据库上下文设置为 sample_data_dev，如下截图所示。
   ![Set the database删除)
3. 从演示笔记本运行 cell #3，以诊断与嵌套循环连接相关的查询性能问题。
   ![Step删除)

查询的运行时间约为 12 秒 ，如查询编辑器 v2 的结果面板所示。
![Step 4删除)

1. 运行 cell #5 从 系统视图中捕获 查询 ID ，根据您在前一步骤中设置的查询标签进行过滤。
   ![Cell删除)
2. 在 Amazon Redshift 控制台中，导航窗格选择 查询和加载 ，选择原始执行查询的集群名称，如下图所示。
   ![Query and删除)
3. 这将打开新的查询分析器。在 查询历史 部分选择 连接到数据库。成功连接后，您会看到状态显示为 已连接，并显示查询历史，如下图所示。
   ![Connect to删除)
4. 您可以通过 查询 ID 或 进程 ID 找到您的查询。输入在前面步骤中捕获的查询 ID 以过滤长时间运行的查询，选择对应的查询 ID，如下图所示。
   ![Search删除)
5. 在 查询计划 部分，选择 子查询 1，如图所示。如果有多个子查询，则需要检查每一个子查询的性能问题。
   ![Child删除)这将以树状视图打开查询计划，并在侧边面板显示附加的度量指标。您可以快速分析查询流、片段和步骤。有关流、片段和步骤的更多信息，请参阅 在 Amazon Redshift 数据库开发者指南中。
6. 开启 查看流 ，在 流 侧边面板中调查并识别哪个流的执行时间最长。在这种情况下，流 ID 5 是查询耗时最多的部分，如下图所示。
   ![Enable view删除)
7. 在 流 侧边面板中，在 ID 下选择 5 ，以进一步分析流。流 5 显示为 嵌套循环 步骤，如下图所示。
   ![Nestloop删除)
8. 选择 嵌套循环 步骤以进一步分析。侧边面板将显示步骤详情及嵌套循环连接的附加指标。
9. 从 步骤详情 - 嵌套循环 ，我们可以检查 输入行 与 输出行 相比的情况，如下图所示。在这种情况下，由于与 Store_returns 表的交叉连接，287,514 的输入行膨胀到 950,233,770 行，从而导致查询变慢。
   ![Nestloop step删除)
10. 通过在 store_sales 和 store_returns 之间引入连接条件修复查询。运行查询编辑器 v2 演示笔记本中的 cell #7。重新编写的查询运行仅需 307 毫秒 。
    ![Cell删除)

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

1. 为了演示数据分布不理想，运行查询编辑器 v2 演示笔记本的 cell #10，将 web_sales 和 web_returns 表的分布样式更改为 均匀 。
   ![Cell删除)
2. 运行 cell #12。如查询编辑器的运行时间所示，查询运行时间为 409 毫秒 。
   ![Cell删除)
3. 按照 用例 1 中的步骤 3–10 定位 query_id，并打开查询分析器查看前述查询。
4. 在前述查询的查询分析器页面，开启 查看流 。在 流 侧边面板中，调查并识别哪个流的执行时间最长。在这种情况下，流 ID 6 是查询耗时最多的部分，如下图所示。
   ![View删除)
5. 在 ID 下，选择 6 以进行进一步分析。
   ![Streams side删除)

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

1. 通过在参与连接的表 web_sales 和 web_returns 上选择适当的分布键来修复此不理想的数据分布模式。要更改分布样式，请运行演示笔记本的 cell #14 更改表命令。
   ![Cell删除)
2. 在前述命令执行完成后，运行 cell #16 重新执行选择查询。更新分布样式为分布键后，查询在查询编辑器中完成仅需 244 毫秒 。
   ![Cell删除)
3. 在查询分析器视图中，开启 查看流 ，注意到 流 ID 5 当前耗时最多，完成仅需 8 毫秒 ，相比上一步增加到 13 毫秒的耗时明显减少。
   ![View删除)
4. 在 流 侧边面板中，在 ID 下选择 5 进行更深入的剖析，然后选择 哈希连接 。如以下截图所示，在将 web_sales 和 web_returns 表的分布样式更改为分布键后，查询运行时不需要重新分配，导致优化性能的实现。
   ![Hashjoin删除)

注意事项

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

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