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/)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 排序索引鍵
**注意**
建議您使用 `SORTKEY AUTO` 建立資料表。如果您這麼做，Amazon Redshift 會使用自動資料表最佳化來選擇排序索引鍵。如需詳細資訊，請參閱[自動資料表最佳化](t_Creating_tables.md)。本節的其餘部分會提供有關排序順序的詳細資訊。
或者，建立資料表時，您可以定義一或多個資料欄做為*排序索引鍵*。當資料最初載入至空的資料表時，資料列會依排序儲存在磁碟上。排序索引鍵資料欄的相關資訊會傳遞至查詢規劃器，而且規劃器會使用此資訊，來建構利用資料排序方式的計劃。如需詳細資訊，請參閱[CREATE TABLE](r_CREATE_TABLE_NEW.md)。如需建立排序索引鍵時最佳作法的資訊，請參閱 [選擇最佳的排序索引鍵](c_best-practices-sort-key.md)。
排序可以有效率地處理限制範圍的述詞。Amazon Redshift 將單欄式資料儲存在 1 MB 磁碟區塊中。每個區塊的 min 和 max 值都會儲存為中繼資料的一部分。如果查詢使用範圍受限的述詞，則查詢處理器可以使用 min 和 max 值，在資料表掃描期間快速地略過大量區塊。例如，假設資料表儲存了依日期排序的五年資料，而查詢指定了一個月的日期範圍。在這種情況下，您最多可以從掃描中移除 98% 的磁碟區塊。如果未排序資料，則必須掃描更多的磁碟區塊 (可能全部)。
您可以指定複合或交錯排序索引鍵。當查詢述詞使用*字首*，即依序的排序索引鍵子集時，複合排序索引鍵更有效。交錯排序索引鍵對排序索引鍵中的每個資料欄都提供相等的權重，所以查詢述詞可以使用構成排序索引鍵之資料欄的任何子集，順序不拘。
若要了解選擇的排序索引鍵對查詢效能的影響，請使用 [EXPLAIN](r_EXPLAIN.md) 命令。如需詳細資訊，請參閱[查詢計劃和執行工作流程](c-query-planning.md)。
若要定義排序類型，請使用 INTERLEAVED 或 COMPOUND 關鍵字與 CREATE TABLE 或 CREATE TABLE AS 陳述式搭配。預設值為 COMPOUND。當您使用 INSERT、UPDATE 或 DELETE 操作定期更新資料表時，建議使用 COMPOUND。INTERLEAVED 排序索引鍵最多可以使用八個資料欄。視您的資料和叢集大小而定，VACUUM REINDEX 所需的時間會比 VACUUM FULL 大幅增加，因為它會額外進行交錯排序索引鍵分析。交錯資料表的排序和合併操作可能需要更長的時間，因為交錯排序可能需要重新排列比複合排序更多的資料列。
若要檢視資料表的排序索引鍵，請查詢 [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md) 系統檢視。
**Topics**
+ [多維資料佈局 (預覽版)](t_Sorting_mutidimensional-sort-key.md)
+ [複合排序索引鍵](t_Sorting_data-compound.md)
+ [交錯排序索引鍵](t_Sorting_data-interleaved.md)
# 多維資料佈局 (預覽版)
多維資料配置排序索引鍵是一種 AUTO 排序索引鍵類型，以工作負載中找到的重複述詞為基礎。如果您的工作負載具有重複述詞，Amazon Redshift 可以透過共置滿足重複述詞的資料列來改善資料表掃描效能。多維資料配置排序索引鍵會藉由分析工作負載中出現的重複述詞來存放資料，而不是以嚴格的資料欄順序存放資料表的資料。在工作負載中可以找到多個重複述詞。根據您的工作負載，這種排序索引鍵可以改善許多述詞的效能。Amazon Redshift 會自動判斷使用 `AUTO` 排序索引鍵定義的資料表是否應該使用排序索引鍵方法。
例如，假設您的資料表的資料是按照資料欄排序。可能需要檢查許多資料區塊，藉以判斷該資料是否符合工作負載中的述詞。但是，如果資料是按照述詞順序儲存在磁碟上，則需要掃描較少區塊以滿足查詢。在這種情況下，使用多維資料配置排序索引鍵是有好處的。
若要檢視查詢是否使用多維資料配置索引鍵，請參閱 [SYS\$1QUERY\$1DETAIL](SYS_QUERY_DETAIL.md) 視觀表的 `step_attribute` 資料欄。當該值為 `multi-dimensional`，則將多維資料配置用於查詢。
若要防止 Amazon Redshift 使用多維資料配置排序索引鍵，請選擇不同的資料表排序索引鍵選項。`SORTKEY AUTO`如需 SORTKEY 選項的詳細資訊，請參閱 [CREATE TABLE](r_CREATE_TABLE_NEW.md)。
# 複合排序索引鍵
複合索引鍵是由排序索引鍵定義中列出的所有資料欄組成，並依它們的列出順序排列。當查詢的篩選條件套用條件 (例如篩選條件和聯結) 來使用排序索引鍵的字首時，複合排序索引鍵最有用。當查詢僅依賴次要排序資料欄，而未參考主要資料欄時，複合排序的效能優勢會降低。COMPOUND 是預設排序類型。
複合排序索引鍵可加快聯結、GROUP BY 和 ORDER BY 操作，以及使用 PARTITION BY 和 ORDER BY 的視窗函數。例如，在聯結資料欄上分佈和預先排序資料時，通常比雜湊聯結還要快的合併聯結更為可行。複合排序索引鍵也可協助改善壓縮。
當您將資料列新增至已包含資料的已排序資料表時，未排序的區域會擴大，因而對效能產生重大影響。當資料表使用交錯排序時，效果更明顯，尤其是排序資料欄包含單調增加的資料 (例如日期或時間戳記資料欄) 時更明顯。執行 VACUUM 操作 (尤其在大型資料載入之後更應執行)，來重新排序和重新分析資料。如需詳細資訊，請參閱[減少未排序區域的大小](vacuum-managing-vacuum-times.md#r_vacuum_diskspacereqs)。在清空以重新排序資料之後，建議做法是執行 ANALYZE 命令來更新查詢規劃器的統計中繼資料。如需詳細資訊，請參閱[分析資料表](t_Analyzing_tables.md)。
# 交錯排序索引鍵
交錯排序可對排序索引鍵中的每個資料欄或資料欄子集提供相等的權重。如果多個查詢使用不同資料欄進行篩選，則您通常可以使用交錯排序樣式來改善那些查詢的效能。當查詢在次要排序資料欄上使用限制性述詞時，相較於複合排序，交錯排序可大幅改善查詢效能。
**重要**
不要在具有依序增加屬性 (如身分資料欄、日期或時間戳記) 的資料欄上使用交錯排序索引鍵。
透過實作交錯排序索引鍵所獲得的效能改善，應該與增加的載入和清空時間進行權衡。
交錯排序與高度選擇性查詢搭配最有效，因為這些查詢會在 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)。
**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)。