从补丁 198 开始，Amazon Redshift 将不再支持创建新的 Python UDF。现有的 Python UDF 将继续正常运行至 2026 年 6 月 30 日。有关更多信息，请参阅[博客文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。

# 分析查询摘要
<a name="c-analyzing-the-query-summary"></a>

要获取比 [EXPLAIN](r_EXPLAIN.md) 生成的查询计划更详细的执行步骤和统计数据，请使用 [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md) 和 [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md) 系统视图。

SVL\$1QUERY\$1SUMMARY 按流提供查询统计数据。您可以利用它提供的信息发现与高昂成本步骤、耗时步骤及写入磁盘步骤有关的问题。

SVL\$1QUERY\$1REPORT 系统视图为您提供与 SVL\$1QUERY\$1SUMMARY 相似的信息，但其按计算节点切片而非按流提供信息。您可以利用切片级信息检测跨集群的不均匀数据分配（也称作数据分配偏斜），后者会导致某些节点执行更多的工作，从而影响查询的性能。

**Topics**
+ [使用 SVL\$1QUERY\$1SUMMARY 视图](using-SVL-Query-Summary.md)
+ [使用 SVL\$1QUERY\$1REPORT 视图](using-SVL-Query-Report.md)
+ [将查询计划映射到查询摘要](query-plan-summary-map.md)

# 使用 SVL\$1QUERY\$1SUMMARY 视图
<a name="using-SVL-Query-Summary"></a>

要使用 [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md) 按数据流分析查询摘要信息，请执行以下操作：

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

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

   检查 `substring` 字段中的截断查询文本来确定哪些 `query` 值代表您的查询。如果您已多次运行查询，请使用具有较低 `elapsed` 值的行中的 `query` 值。这是已编译的行。如果运行多个查询，则可以增大 LIMIT 子句使用的值，以确保将查询包含在内。

1. 从查询的 SVL\$1QUERY\$1SUMMARY 中选择。按流、分段和步骤对结果进行排序：

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

   下面是示例结果。  
![\[SVL_QUERY_SUMMARY 中与给定查询匹配的行的示例结果。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/svl_query_summary_results.png)

1. 使用 [将查询计划映射到查询摘要](query-plan-summary-map.md) 中的信息将步骤映射到查询计划中的操作。它们应具有大致相同的行和字节值（查询计划中的行 \$1 宽度）。如果没有，请参阅[表统计数据缺失或过时](query-performance-improvement-opportunities.md#table-statistics-missing-or-out-of-date)了解建议的解决方案。

1. 查看在任何步骤中 `is_diskbased` 字段的值是否都为 `t`（真）。哈希、聚合和排序是指在系统没有足够的内存用于查询处理的情况下可能会将数据写入磁盘的运算符。

   如果 `is_diskbased` 为真，请参阅 [分配给查询的内存不足](query-performance-improvement-opportunities.md#insufficient-memory-allocated-to-the-query) 了解建议的解决方案。

1. 查看 `label` 字段值，并查看步骤中是否存在 AGG-DIST-AGG 序列。它的存在表明聚合分两步，其成本高昂。要解决此问题，请将 GROUP BY 子句更改为使用分配键（如果有多个键，则为第一个键）。

1. 查看每个分段的 `maxtime` 值（该值在分段中的所有步骤中相同）。标识具有最高 `maxtime` 值的分段，并查看此分段中的以下运算符的步骤。
**注意**  
较高的 `maxtime` 值并不一定表示分段出现问题。尽管值很高，但该分段可能不需要很长时间来处理。流中的所有分段都开始统一计时。但是，从上游段获得数据前，某些下游段可能无法运行。这可能导致它们看起来需要长时间执行，因为它们的 `maxtime` 值包含等待时间和处理时间。
   + **BCAST 或 DIST**：在这些情况下，`maxtime` 值较大可能是由重新分配大量的行造成的。有关建议的解决方案，请参阅[非最优数据分配](query-performance-improvement-opportunities.md#suboptimal-data-distribution)。
   + **HJOIN（哈希联接）**：如果所涉及的步骤的 `rows` 字段值比查询的最终 RETURN 步骤的 `rows` 值高很多，请参阅 [哈希联接](query-performance-improvement-opportunities.md#hash-join) 了解建议的解决方案。
   + **SCAN/SORT**：查找联接步骤之前的 SCAN、SORT、SCAN、MERGE 步骤序列。此模式表示正在扫描、排序未排序的数据，然后将其与表的排序区域合并。

     查看 SCAN 步骤的行值是否比查询的最终 RETURN 步骤中的行值高很多。此模式表示执行引擎正在扫描稍后将丢弃的行，这样做效率低下。有关建议的解决方案，请参阅[谓词限制性不足](query-performance-improvement-opportunities.md#insufficiently-restrictive-predicate)。

     如果 SCAN 步骤的 `maxtime` 值较高，请参阅 [非最优 WHERE 子句](query-performance-improvement-opportunities.md#suboptimal-WHERE-clause) 了解建议的解决方案。

     如果 SORT 步骤的 `rows` 值较高，请参阅[未排序或排序错乱的行](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows)了解建议的解决方案。

1. 查看最终 RETURN 步骤前 5-10 步的 `rows` 和 `bytes` 值，以了解返回到客户端的数据量。这个过程可以说是一门艺术。

   例如，在下面的示例查询摘要中，第三个 PROJECT 步骤提供了一个 `rows` 值，但没有提供 `bytes` 值。通过在前面的步骤中查找具有相同 `rows` 值的步骤，可以找到同时提供行和字节信息的 SCAN 步骤。

    示例结果如下。  
![\[查询摘要结果中的一行，是 SCAN 步骤，同时包含行和字节信息。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/rows_and_bytes.png)

   如果要返回量异常大的数据，请参阅 [极大结果集](query-performance-improvement-opportunities.md#very-large-result-set) 了解建议的解决方案。

1. 查看任何步骤的 `bytes` 与其他步骤相比是否相对 `rows` 值较高。此模式说明您选择了大量列。有关建议的解决方案，请参阅[大型 SELECT 列表](query-performance-improvement-opportunities.md#large-SELECT-list)。

# 使用 SVL\$1QUERY\$1REPORT 视图
<a name="using-SVL-Query-Report"></a>

要使用 [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md) 按切片分析查询摘要信息，请执行以下操作：

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

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

   检查 `substring` 字段中的截断查询文本来确定哪些 `query` 值代表您的查询。如果您已多次运行查询，请使用具有较低 `elapsed` 值的行中的 `query` 值。这是已编译的行。如果运行多个查询，则可以增大 LIMIT 子句使用的值，以确保将查询包含在内。

1. 从查询的 SVL\$1QUERY\$1REPORT 中选择。按分段、步骤、elapsed\$1time 和行对结果进行排序：

   ```
   select * from svl_query_report where query = MyQueryID order by segment, step, elapsed_time, rows;
   ```

1. 对于每个步骤，检查以查看处理的所有切片数是否与行数大致相同：  
![\[用于运行查询的数据切片列表。每个切片处理的行数大致相同。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/SVL_QUERY_REPORT_rows.png)

   此外，检查以查看所有切片所花费的时间是否大致相同：  
![\[用于运行查询的数据切片列表。每个切片所需的时间大致相同。\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/images/SVL_QUERY_REPORT_elapsed_time.png)

   这些值存在较大的差异可能表明由于此特定查询的分配方式不佳而导致数据分布偏差。有关建议的解决方案，请参阅[非最优数据分配](query-performance-improvement-opportunities.md#suboptimal-data-distribution)。

# 将查询计划映射到查询摘要
<a name="query-plan-summary-map"></a>

分析查询摘要时，可以将查询计划中的操作映射到查询摘要中的步骤（由标签字段值标识），从而获得更多细节。下表将查询计划操作映射到查询摘要步骤。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/redshift/latest/dg/query-plan-summary-map.html)