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

您可以使用查詢計劃來識別可將分佈樣式最佳化的候選者。

在做出初始設計決策之後，請建立資料表、將資料載入其中，然後測試它們。使用儘可能接近真實資料的測試資料集。測量載入時間做為比較的基準。

評估哪些查詢代表您預期執行成本最高的查詢，尤指使用聯結和彙總的查詢。比較各種設計選項的執行期。比較執行期時，請不要將第一次執行查詢的時間列入計算，因為第一次執行期包含編譯時間。

**DS\_DIST\_NONE**  
不需要重新分佈，因為對應配量是在運算節點上共置。通常您將只有一個 DS\_DIST\_NONE 步驟，即事實資料表與某個維度資料表之間的聯結。

**DS\_DIST\_ALL\_NONE**  
不需要重新分佈，因為內部資料表已使用 DISTSTYLE ALL。整個資料表位於每個節點上。

**DS\_DIST\_INNER**  
重新配送內部資料表。

**DS\_DIST\_OUTER**  
重新配送外部資料表。

**DS\_BCAST\_INNER**  
將整個內部資料表的副本播送至所有運算節點。

**DS\_DIST\_ALL\_INNER**  
因為外部資料表使用 DISTSTYLE ALL，會將整個內部資料表重新配送至單一配量。

**DS\_DIST\_BOTH**  
重新配送這兩個資料表。

**DS\_DIST\_ERR**  
當資料表未選取分佈樣式時。

DS\_DIST\_NONE 和 DS\_DIST\_ALL\_NONE 都是不錯的選擇。它們指出該步驟不需要重新分佈，因為所有聯結已共置。

DS\_DIST\_INNER 表示步驟將可能有相當高的成本，因為內部資料表正在重新分佈至節點。DS\_DIST\_INNER 指出外部資料表已適當地分佈在聯結索引鍵上。將內部資料表的分佈索引鍵設為聯結索引鍵，以將此項轉換為 DS\_DIST\_NONE。在某些情況下，無法在聯結索引鍵上分佈內部資料表，因為外部資料表不會在聯結索引鍵上分佈。如果是這種情況，請評估是否對內部資料表使用 ALL 分佈。如果資料表未經常或廣泛更新，而且大到足以帶來高重新分佈成本，請將分佈樣式變更為 ALL，然後重新測試。ALL 分佈會導致載入時間增加，因此當您重新測試時，請將載入時間併入您的評估因素中。

DS\_DIST\_ALL\_INNER 不是好選擇。它表示整個內部資料表已重新分佈至單一配量，因為外部資料表使用 DISTSTYLE ALL，以便整個外部資料表的副本位於每個節點上。這會在單一節點上造成一連串無效的聯結執行期，而不是使用所有節點來善用平行執行期。DISTSTYLE ALL 主要只用於內部聯結資料表。反之，指定分佈索引鍵或甚至對外部資料表使用分佈。

DS\_BCAST\_INNER 和 DS\_DIST\_BOTH 不是好選擇。通常，這些重新分佈之所以發生，原因是未在資料表的分佈索引鍵上聯結資料表。如果事實資料表尚未有分佈索引鍵，請將聯結資料欄指定為這兩個資料表的分佈索引鍵。如果事實資料表已在另一個資料欄上具有分佈索引鍵，則請評估變更分佈索引鍵來共置此聯結是否將改善整體效能。如果變更外部資料表的分佈索引鍵不是最佳選擇，則您可以對內部資料表指定 DISTSTYLE ALL 來實現共置。

 下列範例顯示具有 DS\_BCAST\_INNER 和 DS\_DIST\_NONE 標籤之查詢計劃的一部分。

```
->  XN Hash Join DS_BCAST_INNER  (cost=112.50..3272334142.59 rows=170771 width=84)
        Hash Cond: ("outer".venueid = "inner".venueid)
        ->  XN Hash Join DS_BCAST_INNER  (cost=109.98..3167290276.71 rows=172456 width=47)
              Hash Cond: ("outer".eventid = "inner".eventid)
              ->  XN Merge Join DS_DIST_NONE  (cost=0.00..6286.47 rows=172456 width=30)
                    Merge Cond: ("outer".listid = "inner".listid)
                    ->  XN Seq Scan on listing  (cost=0.00..1924.97 rows=192497 width=14)
                    ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=24)
```

在變更維度資料表來使用 DISTSTYLE ALL 之後，相同查詢的查詢計劃便會顯示 DS\_DIST\_ALL\_NONE 代替 DS\_BCAST\_INNER。另外，聯結步驟的相對成本會發生大幅變更。與之前查詢中的 `3272334142.59` 相比，總成本是 `14142.59`。

```
->  XN Hash Join DS_DIST_ALL_NONE  (cost=112.50..14142.59 rows=170771 width=84)
        Hash Cond: ("outer".venueid = "inner".venueid)
        ->  XN Hash Join DS_DIST_ALL_NONE  (cost=109.98..10276.71 rows=172456 width=47)
              Hash Cond: ("outer".eventid = "inner".eventid)
              ->  XN Merge Join DS_DIST_NONE  (cost=0.00..6286.47 rows=172456 width=30)
                    Merge Cond: ("outer".listid = "inner".listid)
                    ->  XN Seq Scan on listing  (cost=0.00..1924.97 rows=192497 width=14)
                    ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=24)
```