从补丁 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/)。

# 使用 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)。