Redshift - 如何识别查询中的低性能区域？答案

【问题标题】：Redshift - How to identify low performing areas in Query?Redshift - 如何识别查询中的低性能区域？
【发布时间】：2018-07-27 13:15:59
【问题描述】：

背景：我是 Redshift 和 PostgreSQL 的新手，想知道如何提高我的查询性能。我需要关于执行时间、使用的内存量或我运行的查询的其他相关指标方面的反馈。

问题：是否有一个简单的 SQL 命令/方法（？）来了解（至少是一个粗略的想法）查询中的哪些区域执行时间最长？

附加信息：我经常使用这样的公用表表达式：

WITH level1 as (SELECT Customerid 
                FROM customer_tbl
                WHERE year > 2000), 
level2 as (SELECT level1.Customerid,
                  purchasing_tbl.item,
                  purchasing_tbl.price
           FROM level1
           LEFT JOIN purchasing_tbl
                  ON purchasing_tbl.id = level1.Customerid

通常这种类型的结构可能有 10 多个级别，通常包括要麻烦得多（就更多的连接而言，where、case、具有不同聚合的窗口函数）。

在尝试提高性能时，了解例如与 level2 相比，level10 的执行时间。

客户：我使用 DBeaver 5.1.1。

【问题讨论】：

在 Postgres 中你可以使用 explain (analyze) ... 但我认为 Redshift 中不可用
是的，说明在 Redshift 中有效。这是一个很好的起点：docs.aws.amazon.com/redshift/latest/dg/c-the-query-plan.html 和 docs.aws.amazon.com/redshift/latest/dg/r_EXPLAIN.html
更多用于检查查询计划的选项 - 估计与实际，包括 TIMING：docs.aws.amazon.com/redshift/latest/mgmt/… AND docs.aws.amazon.com/redshift/latest/dg/… 这些列出了一些我也发现有帮助的系统视图。
@VictorDiLeo 看起来像我要找的东西！你不会碰巧使用它，例如在示例中的“level2”上并作为答案？很可能我会感谢您的回复。
需要注意的几件事：在红移中，cte 没有实现。它只是嵌套的捷径（有时 ctes 可能非常昂贵，除非您意识到正在生成什么）。并且 - 确保您再次运行您的 sql（以避免计算编译时间）并且没有在 redshift 中使用缓存结果。

标签： sql amazon-redshift query-performance

【解决方案1】：

STL_QUERY 是 Redshift 中的一个系统视图，其中包含查询时间： https://docs.aws.amazon.com/redshift/latest/dg/r_STL_QUERY.html

select starttime, enddtime, * from stl_query where querytxt = '' 按开始时间顺序排列限制 100 ;

【讨论】：

【解决方案2】：

有很多方法可以了解次优查询。

以下链接提供了不同的检查步骤。

https://docs.aws.amazon.com/redshift/latest/dg/query-performance-improvement-opportunities.html#suboptimal-data-distribution

AWS 提供了一些实用程序 - 在 GIT Hub 中可用。

https://github.com/awslabs/amazon-redshift-utils

这两种材料在调优查询方面都非常有用。

问候，罗摩

【讨论】：