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="query-performance-improvement-opportunities"></a>

以下是影響 Amazon Redshift 查詢效能的一些常見問題，以及其診斷和解決方式的指示。

**Topics**
+ [

## 資料表統計資訊遺漏或過時
](#table-statistics-missing-or-out-of-date)
+ [

## 巢狀迴圈
](#nested-loop)
+ [

## 雜湊聯結
](#hash-join)
+ [

## 幽靈資料列或未遞交的資料列
](#ghost-rows-or-uncommitted-rows)
+ [

## 未排序或排序錯誤的資料列
](#unsorted-or-mis-sorted-rows)
+ [

## 次佳資料分佈
](#suboptimal-data-distribution)
+ [

## 配置給查詢的記憶體不足
](#insufficient-memory-allocated-to-the-query)
+ [

## 次佳的 WHERE 子句
](#suboptimal-WHERE-clause)
+ [

## 不足的限制性述詞
](#insufficiently-restrictive-predicate)
+ [

## 非常大的結果集
](#very-large-result-set)
+ [

## 大型 SELECT 清單
](#large-SELECT-list)

## 資料表統計資訊遺漏或過時
<a name="table-statistics-missing-or-out-of-date"></a>

如果資料表統計資料遺漏或過時，您可能會看見下列：
+ EXPLAIN 命令結果中有警告訊息。
+ STL\$1ALERT\$1EVENT\$1LOG 中遺漏統計資料提醒事件。如需詳細資訊，請參閱[檢閱查詢提醒](c-reviewing-query-alerts.md)。

若要修正此問題，請執行 [ANALYZE](r_ANALYZE.md)。

## 巢狀迴圈
<a name="nested-loop"></a>

如果出現巢狀迴路，您可能會在 STL\$1ALERT\$1EVENT\$1LOG 中看見巢狀迴路提醒事件。您也可以透過執行[識別具有巢狀迴圈的查詢](identify-queries-with-nested-loops.md)中的查詢，來識別此類型的事件。如需詳細資訊，請參閱[檢閱查詢提醒](c-reviewing-query-alerts.md)。

若要修正此問題，請檢閱您的查詢以取得交叉聯結並在可能時加以移除。交叉聯結是沒有聯結條件的聯結，會造成兩個資料表的笛卡兒乘積。它們通常會以巢狀迴圈聯結的形式執行，這是可能的聯結類型中最慢的。

## 雜湊聯結
<a name="hash-join"></a>

如果出現雜湊聯結，您可能會看見下列：
+ 查詢計畫中的雜湊和雜湊聯結操作。如需詳細資訊，請參閱[分析查詢計劃](c-analyzing-the-query-plan.md)。
+ 區段中的 HJOIN 步驟具有 SVL\$1QUERY\$1SUMMARY 中最高的 maxtime 值。如需詳細資訊，請參閱[使用 SVL\$1QUERY\$1SUMMARY 檢視](using-SVL-Query-Summary.md)。

若要修正此問題，您可以採取兩個方法：
+ 如果可能，重新寫入查詢以使用合併聯結。指定同時為散發索引鍵和排序索引鍵的聯結資料欄即可執行此動作。
+ 如果 SVL\$1QUERY\$1SUMMARY 的 HJOIN 步驟的資料列欄位相較於查詢中最終 RETURN 步驟中的資料列值有非常高的值，請檢查您是否可以重新寫入查詢以在唯一資料欄上聯結。當查詢未在唯一資料欄上聯結時，例如主要索引鍵，它會增加聯結中牽涉的資料列數量。

## 幽靈資料列或未遞交的資料列
<a name="ghost-rows-or-uncommitted-rows"></a>

如果出現幽靈資料列或未遞交的資料列，您可能會在 STL\$1ALERT\$1EVENT\$1LOG 看見提醒事件，指出過量的幽靈資料列。如需詳細資訊，請參閱[檢閱查詢提醒](c-reviewing-query-alerts.md)。

若要修正此問題，您可以採取兩個方法：
+ 查看 Amazon Redshift 主控台的**載入**索引標籤，以瞭解任何查詢資料表上的作用中載入操作。如果您看見作用中的載入操作，採取動作之前，請等候那些操作完成。
+ 如果沒有作用中載入操作，請在查詢資料表上執行 [VACUUM](r_VACUUM_command.md) 來移除刪除的資料列。

## 未排序或排序錯誤的資料列
<a name="unsorted-or-mis-sorted-rows"></a>

如果出現未排序或排序錯誤的資料列，您可能會在 STL\$1ALERT\$1EVENT\$1LOG 中看見非常高的篩選條件提醒事件。如需詳細資訊，請參閱[檢閱查詢提醒](c-reviewing-query-alerts.md)。

您也可以透過執行 [識別具有資料扭曲或未排序資料列的資料表](identify-tables-with-data-skew-or-unsorted-rows.md) 中的查詢，查看您的查詢中是否任何資料表有大型未排序的區域。

若要修正此問題，您可以採取兩個方法：
+ 在查詢資料表上執行 [VACUUM](r_VACUUM_command.md) 來重新排序資料列。
+ 檢閱查詢資料表上的排序索引鍵，以查看是否有可以進行的任何改善。請記得評估此查詢的效能與其他重要查詢和整體系統的效能，再進行任何變更。如需詳細資訊，請參閱[排序索引鍵](t_Sorting_data.md)。

## 次佳資料分佈
<a name="suboptimal-data-distribution"></a>

如果資料配送為次佳，您可能會看見下列：
+ STL\$1ALERT\$1EVENT\$1LOG 中出現序列執行、大型播送或大型配送提醒事件。如需詳細資訊，請參閱[檢閱查詢提醒](c-reviewing-query-alerts.md)。
+ 針對指定步驟，配量未處理大約相同數量的資料列。如需詳細資訊，請參閱[使用 SVL\$1QUERY\$1REPORT 檢視](using-SVL-Query-Report.md)。
+ 針對指定步驟，配量未耗費大約相同的時間量。如需詳細資訊，請參閱[使用 SVL\$1QUERY\$1REPORT 檢視](using-SVL-Query-Report.md)。

如果前述中無一成立，您也可以透過執行 [識別具有資料扭曲或未排序資料列的資料表](identify-tables-with-data-skew-or-unsorted-rows.md) 中的查詢，查看您的查詢中是否有任何資料表有資料偏度。

若要修正此問題，查看查詢中資料表的分佈樣式，並確認是否可以進行任何改善。請記得評估此查詢的效能與其他重要查詢和整體系統的效能，再進行任何變更。如需詳細資訊，請參閱[分配資料以實現查詢最佳化](t_Distributing_data.md)。

## 配置給查詢的記憶體不足
<a name="insufficient-memory-allocated-to-the-query"></a>

如果對您的查詢配置了不足的記憶體，您可能會在 SVL\$1QUERY\$1SUMMARY 中看見某個步驟的 `is_diskbased` 值為 true。如需詳細資訊，請參閱[使用 SVL\$1QUERY\$1SUMMARY 檢視](using-SVL-Query-Summary.md)。

若要修正此問題，請透過暫時增加它所使用查詢位置的數量，為查詢配置更多記憶體。工作負載管理 (WLM) 會在查詢佇列中預留位置，大約等同於為佇列設定的並行層級。例如，具有並行層級 5 的佇列有 5 個位置。指派給佇列的記憶體會平均配置到每個位置。對一個查詢指派數個位置可讓該查詢存取所有那些位置的記憶體。如需如何暫時增加查詢位置的相關資訊，請參閱[wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md)。

## 次佳的 WHERE 子句
<a name="suboptimal-WHERE-clause"></a>

如果您的 WHERE 子句造成過度的資料表掃描，您可能會在 SVL\$1QUERY\$1SUMMARY 中具有最高 `maxtime` 值的區段中看見 SCAN 步驟。如需詳細資訊，請參閱[使用 SVL\$1QUERY\$1SUMMARY 檢視](using-SVL-Query-Summary.md)。

若要修正此問題，請根據最大資料表的主要排序資料欄，將 WHERE 子句新增至查詢。這種方法可縮短降低掃描時間。如需詳細資訊，請參閱[設計資料表的 Amazon Redshift 最佳實務](c_designing-tables-best-practices.md)。

## 不足的限制性述詞
<a name="insufficiently-restrictive-predicate"></a>

如果您的查詢有不足的限制性述詞，您可能會在 SVL\$1QUERY\$1SUMMARY 中具有最高 `maxtime` 值的區段中看見 SCAN 步驟，其相較於查詢中最終 RETURN 步驟中的 `rows` 值具有非常高的 `rows` 值。如需詳細資訊，請參閱[使用 SVL\$1QUERY\$1SUMMARY 檢視](using-SVL-Query-Summary.md)。

若要修正此問題，請嘗試新增述詞至查詢，或讓現有述詞更具限制性來縮小列輸出。

## 非常大的結果集
<a name="very-large-result-set"></a>

如果您的查詢傳回非常大的結果集，請考慮重新寫入查詢，以使用 [UNLOAD](r_UNLOAD.md) 來寫入結果至 Amazon S3。此方式藉由利用平行處理，有效改善 RETURN 步驟的效能。如需檢查非常大型結果集的相關資訊，請參閱[使用 SVL\$1QUERY\$1SUMMARY 檢視](using-SVL-Query-Summary.md)。

## 大型 SELECT 清單
<a name="large-SELECT-list"></a>

如果您的查詢有異常大的 SELECT 清單，您可能會在 SVL\$1QUERY\$1SUMMARY 中看見相對於 (相較於其他步驟) 任何步驟的 `bytes` 值來得高的 `rows` 值。這個高 `bytes` 值可能是您正選取許多資料欄的指標。如需詳細資訊，請參閱[使用 SVL\$1QUERY\$1SUMMARY 檢視](using-SVL-Query-Summary.md)。

若要修正此問題，請檢閱您要選取的資料欄，並查看是否可移除任何項目。