登录控制台
Amazon Redshift
数据库开发人员指南 (API 版本 2012-12-01)
AWS 文档 » Amazon Redshift » 数据库开发人员指南 » 优化查询性能 » 分析和改进查询 » 分析查询摘要 » 使用 SVL_QUERY_SUMMARY 视图
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅中国的 AWS 服务入门。

使用 SVL_QUERY_SUMMARY 视图

要按流分析查询摘要信息，请执行以下操作：

  1. 运行以下查询以确定查询 ID：

    select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;

    检查 substring 字段中的截断查询文本，以确定哪个 query 值表示您的查询。如果至少运行过该查询两次，则使用 query 值较小的行的 elapsed 值。这是已编译的行。如果您一直在运行多个查询，则可以增大 LIMIT 子句使用的值，以确保将查询包含在内。

  2. 从查询的 SVL_QUERY_SUMMARY 中选择。按流、段和步骤排序结果：

    select * from svl_query_summary where query = MyQueryID order by stm, seg, step;

  3. 使用将查询计划映射到查询摘要中的信息将步骤映射到查询计划中的操作。它们的行数和字节数值（行数 * 查询计划宽度）应大致相同。如果不是这样，请参阅表统计数据缺失或过时了解建议的解决方案。

  4. 查看任意步骤的 is_diskbased 字段的值是否为 t (true)。哈希、聚合和排序是可能向磁盘写入数据的运算符（如果系统没有充足的内存分配给查询处理作业）。

    如果 is_diskbased 为 true，请参阅分配给查询的内存不足了解建议的解决方案。

  5. 查看 label 字段的值，确定步骤中是否存在任意 AGG-DIST-AGG 序列。如果有该序列，则表明存在代价高昂的两步聚合。要解决这一问题，请将 GROUP BY 子句更改为使用分配键（如果存在多个分配键，则是第一个键）。

  6. 查看每个段的 maxtime 值（段中所有步骤的该值应相同）。找出 maxtime 值最大的段，并检查段中的步骤是否存在以下运算符。

    注意

    maxtime 值较大并不一定表示该段存在问题。即使值较大，也不一定需要长时间处理该段。流中的所有段同时开始计时。但是，从上游段获得数据前，某些下游段可能无法运行。这可能导致它们看起来需要长时间执行，因为它们的 maxtime 值包含等待时间和处理时间。

    • BCAST 或 DIST：在这些情况下，maxtime 值较大可能是由重新分配大量的行造成的。有关建议的解决方案，请参阅非最优数据分配。

    • HJOIN（哈希联接）：如果所涉步骤的 rows 字段值较查询最终 RETURN 步骤中的 rows 值大得多，请参阅哈希联接了解建议的解决方案。

    • SCAN/SORT：查找紧接在联接步骤之前的 SCAN、SORT、SCAN、MERGE 步骤序列。该模式指示未排序数据受到扫描、排序，然后与表中的已排序区域合并。

      查看 SCAN 步骤的行数值是否较查询中最终 RETURN 步骤中的行数值大得多。该模式指示执行引擎扫描了稍后丢弃的行，这种操作的效率很低。有关建议的解决方案，请参阅限制性谓词不足。

      如果 SCAN 步骤的 maxtime 值很大，请参阅非最优 WHERE 子句了解建议的解决方案。

      如果 SORT 步骤的 rows 值不为零，请参阅未排序或排序错乱的行了解建议的解决方案。

  7. 查看最终 RETURN 步骤之前的 5-10 步的 rows 和 bytes 值，了解返回到客户端的数据量。执行这一步需要一定的技巧。

    例如，在下面的查询摘要中，可以看到第三步 (PROJECT) 提供了 rows 值，但未提供 bytes 值。通过在之前的步骤中寻找具有相同 rows 值的步骤，您会发现 SCAN 步骤同时提供了行数和字节数信息：

    如果返回不寻常的数据量，请参阅极大结果集了解建议的解决方案。

  8. 与其他步骤比较，查看 bytes 值是否大于任意步骤的 rows 值。这种模式说明您选择了大量列。有关建议的解决方案，请参阅大型 SELECT 列表。