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-plan"></a>

執行 [EXPLAIN](r_EXPLAIN.md) 命令來取得查詢計畫。

分析查詢計畫之前，您應該熟悉如何閱讀它。如果您對於閱讀查詢計畫不熟悉，建議您閱讀[建立和解譯查詢計畫](c-the-query-plan.md)之後再繼續。

若要分析查詢計畫提供的資料，請遵循這些步驟：

1. 識別具有最高成本的步驟。繼續進行其餘步驟時，請專注在那些。

1. 查看聯結類型：
   + **巢狀迴路**：這類聯結的發生通常是因為省略了聯結條件。如需建議的解決方案，請參閱[巢狀迴圈](query-performance-improvement-opportunities.md#nested-loop)。
   + **雜湊和雜湊聯結**：當聯結資料表中的聯結資料欄不是散發索引鍵也不是排序索引鍵時，會使用雜湊聯結。如需建議的解決方案，請參閱[雜湊聯結](query-performance-improvement-opportunities.md#hash-join)。
   + **合併聯結**：不需變更。

1. 注意哪個資料表用於內部聯結，以及哪個用於外部聯結。查詢引擎一般會對內部聯結選擇較小的資料表，以及對外部聯結選擇較大的資料表。如果這類選擇未發生，那麼，您的統計資料很可能過時。如需建議的解決方案，請參閱[資料表統計資訊遺漏或過時](query-performance-improvement-opportunities.md#table-statistics-missing-or-out-of-date)。

1. 查看是否有任何高成本的排序操作。如果有，請參閱[未排序或排序錯誤的資料列](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows)以取得建議的解決方案。

1. 尋找具有高成本操作的下列播送運算子：
   + **DS\_BCAST\_INNER**：表示資料表已廣播至所有運算節點。這對於小資料表來說很好，但對於較大的資料表來說並不理想。
   + **DS\_DIST\_ALL\_INNER**：指出所有工作負載位於單一配量上。
   + **DS\_DIST\_BOTH**：指出繁重的重新配送。

   如需這些情況的建議解決方案，請參閱[次佳資料分佈](query-performance-improvement-opportunities.md#suboptimal-data-distribution)。