Amazon Redshift 將不再支援從修補程式 198 開始建立新的 Python UDFs。現有 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` 值。如果您已執行查詢超過一次，請使用來自具有較低 `query` 值資料列的 `elapsed` 值。那是編譯版本的資料列。如果您已執行許多查詢，您可以提升 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_tw/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` (true) 值。如果系統沒有為查詢處理配置足夠的記憶體，雜湊、彙整和排序為可能將資料寫入至磁碟的運算子。

   如果 `is_diskbased` 為 true，請參閱[配置給查詢的記憶體不足](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 序列。這個模式指出未排序的資料會經過掃描、排序，然後與資料表排序的區域合併。

     查看相較於查詢中最終 RETURN 步驟的資料列值，SCAN 步驟的資料列值是否有非常高的值。這個模式指出執行引擎正在掃描稍後將捨棄的資料列，這樣做缺乏效率。如需建議的解決方案，請參閱[不足的限制性述詞](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_tw/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` 值。如果您已執行查詢超過一次，請使用來自具有較低 `query` 值資料列的 `elapsed` 值。那是編譯版本的資料列。如果您已執行許多查詢，您可以提升 LIMIT 子句使用的值，以確定您的查詢已包含在其中。

1. 從 SVL\$1QUERY\$1REPORT 中，為您的查詢選取資料列。依區段、步驟、經過時間和資料列排列結果：

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

1. 針對每個步驟，查看所有配量是否正處理大約相同數量的資料列：  
![\[用來執行查詢的資料切片清單。每個切片會處理大致相同的列數。\]](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/images/SVL_QUERY_REPORT_rows.png)

   也查看所有配量是否正耗費大約相同的時間量：  
![\[用來執行查詢的資料切片清單。每個切片所花費的時間大致相同。\]](http://docs.aws.amazon.com/zh_tw/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_tw/redshift/latest/dg/query-plan-summary-map.html)