

 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="t_Sorting_data-interleaved"></a>

交錯排序可對排序索引鍵中的每個資料欄或資料欄子集提供相等的權重。如果多個查詢使用不同資料欄進行篩選，則您通常可以使用交錯排序樣式來改善那些查詢的效能。當查詢在次要排序資料欄上使用限制性述詞時，相較於複合排序，交錯排序可大幅改善查詢效能。

**重要**  
不要在具有依序增加屬性 (如身分資料欄、日期或時間戳記) 的資料欄上使用交錯排序索引鍵。

透過實作交錯排序索引鍵所獲得的效能改善，應該與增加的載入和清空時間進行權衡。

交錯排序與高度選擇性查詢搭配最有效，因為這些查詢會在 WHERE 子句中的一個或多個排序索引鍵資料欄上進行篩選，例如 `select c_name from customer where c_region = 'ASIA'`。隨著受限之排序資料欄的數目增加，交錯排序的優勢更明顯。

使用大型資料表時，交錯排序更有效。排序會套用至每個配量。因此，當資料表足夠大到每個配量需要多個 1 MB 區塊時，交錯排序最有效。在這裡，查詢處理器可以使用限制性述詞跳過區塊的顯著比例。若要檢視資料表使用的區塊數目，請查詢 [STV\$1BLOCKLIST](r_STV_BLOCKLIST.md) 系統檢視。

 在單一資料欄上進行排序時，如果資料欄值具有很長的常用字首，則交錯排序可能提供比複合排序更好的效能。例如，URL 通常以 "http://www" 開頭。複合排序索引鍵使用字首中數目受限的字元，因而導致許多索引鍵重複。交錯排序會對區域映射值使用內部壓縮方法，讓它們更能區分常用字首很長的資料欄值。

 將 Amazon Redshift 佈建叢集移轉至 Amazon Redshift Serverless 時，Redshift 會將同時具有交錯排序索引鍵和 DISTSTYLE KEY 的資料表轉換為複合排序索引鍵。不過，只有交錯排序索引鍵的資料表則保持不變。如需分佈樣式的相關資訊，請參閱[使用資料分佈樣式](https://docs.aws.amazon.com//redshift/latest/dg/t_Distributing_data.html)。
<a name="t_Sorting_data-interleaved-reindex"></a>
**VACUUM REINDEX**  
當您將資料列新增至已包含資料的已排序資料表時，效能可能會在一段時間後惡化。複合排序和交錯排序都會發生這種惡化，但是對交錯資料表的影響更大。VACUUM 會還原排序，但對於交錯資料表，此操作可能需要更長的時間，因為合併新的交錯資料可能涉及修改每一個資料區塊。

最初載入資料表時，Amazon Redshift 會分析排序索引鍵資料欄中值的分佈，並使用該資訊以取得排序索引鍵資料欄的最佳交錯。當資料表越來越大時，排序索引鍵資料欄中值的分佈可能會變更或扭曲，尤其是日期或時間戳記資料欄。如果扭曲變得太大，效能可能會受到影響。若要重新分析排序索引鍵並還原效能，請搭配 REINDEX 關鍵字執行 VACUUM 命令。因為它對資料必須進行額外的分析階段，所以對於交錯資料表，VACUUM REINDEX 可能需要比標準 VACUUM 還要長的時間。若要檢視索引鍵分佈扭曲及上次重建索引時間的相關資訊，請查詢 [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) 系統檢視。

如需如何判斷執行 VACUUM 的頻率與執行 VACUUM REINDEX 的時間之相關資訊，請參閱[決定是否重新編製索引](vacuum-managing-vacuum-times.md#r_vacuum-decide-whether-to-reindex)。