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/)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 清空資料表
Amazon Redshift 可以在背景中自動排序及在資料表上執行 VACUUM DELETE 操作。如要在載入或一系列的累加式更新之後清理資料表，您也可以對整個資料庫或個別資料表執行 [VACUUM](r_VACUUM_command.md) 命令。
**注意**
只有具有必要資料表權限的使用者才能有效地清除資料表。若 VACUUM 執行時沒有必要的資料表權限，操作仍會成功完成，但不會有任何作用。如需有效執行 VACUUM 的有效資料表權限清單，請參閱 [VACUUM](r_VACUUM_command.md)。
因此，我們建議視需要清空個別資料表。我們也建議使用此方法，因為清空整個資料庫可能會是相當耗費資源的操作。
## 自動資料表排序
Amazon Redshift 會在背景中自動排序資料，以依據其排序索引鍵的順序維護資料表資料。Amazon Redshift 會追蹤您的掃描查詢，以判斷資料表中的哪些區段適合排序。Amazon Redshift 也會追蹤並行擴展叢集的掃描查詢。對於使用 Amazon Redshift 資料共用的多叢集架構，Amazon Redshift 也會追蹤來自資料網格中取用者叢集/工作群組的掃描查詢，包括不同區域的叢集/工作群組。主要叢集、並行擴展叢集和取用者叢集的掃描統計資料會彙總，以判斷資料表的哪些區段將受益於排序。
取決於系統上的載入，Amazon Redshift 會自動啟動排序。這種自動排序能減少執行 VACUUM 命令以將資料保持在排序索引鍵順序的需求。如果您需要資料完全依照排序索引鍵的順序排序 (例如在大型資料載入後)，您仍然可以手動執行 VACUUM 命令。如要判斷您的資料表是否能從執行 VACUUM SORT 中獲益，請監控 [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md) 中的 `vacuum_sort_benefit` 資料行。
Amazon Redshift 追蹤會掃描每個資料表上使用排序索引鍵的查詢。Amazon Redshift 會估計掃描及篩選每個資料表資料獲得改善的最大百分比 (如果資料表已完全排序的話)。您可以在 [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md) 中的 `vacuum_sort_benefit` 資料行中看見此估計。您可以使用此資料行搭配 `unsorted` 資料行，來判斷查詢何時能從對資料表手動執行 VACUUM SORT 中獲益。`unsorted` 資料行反映了資料表的實體排序順序。`vacuum_sort_benefit` 資料行指定了手動執行 VACUUM SORT 以排序資料表所會造成的影響。
例如，考量以下查詢：
```
select "table", unsorted,vacuum_sort_benefit from svv_table_info order by 1;
```
```
table | unsorted | vacuum_sort_benefit
-------+----------+---------------------
sales | 85.71 | 5.00
event | 45.24 | 67.00
```
針對 “sales” 資料表，即使資料表約 86% 是實體未排序的，因 86% 未排序而造成的查詢效能影響也只有 5%。這可能是因為查詢只存取了資料表的一小部分，或是存取資料表的查詢非常少。針對 “event” 資料表，該資料表約 45% 是實體未排序的。但 67% 的查詢效能影響指出查詢可能存取了資料表的較大部分，或是存取資料表的查詢數相當龐大。“event” 資料表可能會從執行 VACUUM SORT 中獲益。
## 自動清空刪除
當您執行刪除時，資料列會標示為要刪除，但不會移除。Amazon Redshift 會根據資料庫資料表中已刪除的資料列數，在背景中自動執行 VACUUM DELETE 操作。Amazon Redshift 會將 VACUUM DELETE 排程在負載降低的期間執行，並在高負載期間暫停操作。
**Topics**
+ [自動資料表排序](#automatic-table-sort)
+ [自動清空刪除](#automatic-table-delete)
+ [VACUUM 頻率](#vacuum-frequency)
+ [排序階段和合併階段](#vacuum-stages)
+ [清空閾值](#vacuum-sort-threshold)
+ [清空類型](#vacuum-types)
+ [盡可能縮短清空時間](vacuum-managing-vacuum-times.md)
## VACUUM 頻率
您應該根據需求時常進行清空，才能保有一致的查詢效能。判斷執行您的 VACUUM 命令的頻率時，請考慮這些因素：
+ 在您預期叢集上只有最少量活動的時段期間，例如傍晚或指定的資料庫管理時段期間執行 VACUUM。
+ 在維護時段外執行 VACUUM 命令。如需詳細資訊，請參閱[排程維護時段](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html)。
+ 大量未排序的區域會造成較長的清空時間。如果您延遲清空，清空會耗費更長時間，因為必須重新整理更多資料。
+ VACUUM 為 I/O 密集的操作，因此，清空完成所需的時間愈長，對您的叢集執行的並行查詢和其他資料庫操作造成的影響愈大。
+ 對於使用交錯排序的資料表，VACUUM 需要較長的時間。如要評估是否必須重新排序交錯的資料表，請查詢 [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) 檢視。
## 排序階段和合併階段
Amazon Redshift 會在兩個階段中執行清空操作：首先，排序未排序區域中的資料列，然後在必要時，將資料表尾端新排序的資料列與現有資料列合併。清空大型資料表時，清空操作會以一系列的步驟進行，其中包含遞增排序，接著是合併。如果操作失敗或如果 Amazon Redshift 在清空期間離線，部分清空的資料表或資料庫將處於一致的狀態，但您將必須手動重新開始清空操作。遞增排序會遺失，但不需要再次清空失敗之前認可的合併資料列。如果未排序的區域很大，損失的時間可能會很可觀。如需排序和合併階段的相關資訊，請參閱[減少合併列的數量](vacuum-managing-vacuum-times.md#vacuum-managing-volume-of-unmerged-rows)。
使用者可以在清空資料表時加以存取。在清空資料表時您可以執行查詢和寫入操作，但是當 DML 和清空並行執行時，這兩項可能都需要較長時間。如果您在清空期間執行 UPDATE 和 DELETE 陳述式，系統效能可能會降低。遞增合併會暫時封鎖並行 UPDATE 和 DELETE 操作，因此 UPDATE 和 DELETE 操作會在受影響的資料表暫時封鎖遞增合併步驟。DDL 操作，例如 ALTER TABLE，會遭到封鎖，直到資料表的清空操作完成為止。
**注意**
VACUUM 的各種修飾詞都會控制其運作方式。您可以根據當前需求，使用這些修飾詞來制定清空操作。例如，使用 VACUUM RECLUSTER 可透過不執行完整合併操作來縮短清空操作。如需詳細資訊，請參閱[VACUUM](r_VACUUM_command.md)。
## 清空閾值
根據預設，若資料表中超過 95% 的資料列已排序，則 VACUUM 會略過資料表的排序階段。略過排序階段可大幅改善 VACUUM 的效能。若要變更單一資料表的預設排序閾值，在執行 VACUUM 命令時，請包含資料表名稱和 TO *閾值* PERCENT 參數。
## 清空類型
如需不同清空類型的詳細資訊，請參閱 [VACUUM](r_VACUUM_command.md)。
# 盡可能縮短清空時間
Amazon Redshift 會自動排序資料並在背景中執行 VACUUM DELETE。這可以減少執行 VACUUM 命令的需求。清空程序可能相當耗時。根據您資料的性質而定，我們建議依照下列實務進行，以盡可能縮短清空時間。
**Topics**
+ [決定是否重新編製索引](#r_vacuum-decide-whether-to-reindex)
+ [減少未排序區域的大小](#r_vacuum_diskspacereqs)
+ [減少合併列的數量](#vacuum-managing-volume-of-unmerged-rows)
+ [以排序索引鍵順序載入資料](#vacuum-load-in-sort-key-order)
+ [使用時間序列資料表來減少儲存的資料](#vacuum-time-series-tables)
## 決定是否重新編製索引
您通常可以使用交錯的排序樣式大幅改善查詢效能，但如果排序索引鍵資料欄中值的配送變更，效能可能隨著時間降級。
當您一開始使用 COPY 或 CREATE TABLE AS 載入空白的交錯資料表時，Amazon Redshift 會自動建立交錯的索引。如果您最初使用 INSERT 載入交錯的資料表，您之後必須執行 VACUUM REINDEX，才能初始化交錯的索引。
隨著時間，在您新增具有新排序索引鍵值的資料列時，如果排序索引鍵資料欄中值的配送變更，效能可能降級。如果您的新資料列主要在現有排序索引鍵值的範圍內，則不需要重建索引。執行 VACUUM SORT ONLY 或 VACUUM FULL 來還原排序順序。
查詢引擎可以使用排序順序來有效地選取處理查詢需要掃描的資料區塊。針對交錯的排序，Amazon Redshift 會分析排序索引鍵資料欄值，以判斷最佳排序順序。如果隨著資料列新增，索引鍵值的配送變更或偏移，排序策略將不再最佳，而排序的效能優勢將會降級。若要重新分析排序索引鍵配送您可以執行 VACUUM REINDEX。重建索引操作相當耗時，因此，若要決定資料表是否將可從重建索引獲益，請查詢 [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) 檢視。
例如，下列查詢顯示使用交錯排序索引鍵的資料表的詳細資訊。
```
select tbl as tbl_id, stv_tbl_perm.name as table_name,
col, interleaved_skew, last_reindex
from svv_interleaved_columns, stv_tbl_perm
where svv_interleaved_columns.tbl = stv_tbl_perm.id
and interleaved_skew is not null;
tbl_id | table_name | col | interleaved_skew | last_reindex
--------+------------+-----+------------------+--------------------
100048 | customer | 0 | 3.65 | 2015-04-22 22:05:45
100068 | lineorder | 1 | 2.65 | 2015-04-22 22:05:45
100072 | part | 0 | 1.65 | 2015-04-22 22:05:45
100077 | supplier | 1 | 1.00 | 2015-04-22 22:05:45
(4 rows)
```
`interleaved_skew` 的值為比率，指出偏移量。值為 1 表示沒有偏移。如果偏移大於 1.4，VACUUM REINDEX 一般將會改善效能，除非偏移本來就在基礎設定中。
您可以使用 `last_reindex` 中的日期值來判斷自上次重建索引後經過的時間。
## 減少未排序區域的大小
載入大量新資料至已包含資料的資料表，或當您不隨著例行維護操作清空資料表時，未排序的區域會成長。若要避免長時間執行清空操作，請使用下列做法：
+ 根據定期排程執行清空操作。
如果您以小型增量載入您的資料表 (例如代表資料表中資料列總數的每日更新)，定期執行 VACUUM 將有助於確保個別清空操作快速進行。
+ 先執行最大型的載入。
如果您需要使用多個 COPY 操作載入新資料表，請先執行最大的載入。執行初始載入至新的或截斷的資料表時，所有資料會直接載入至排序的區域，因此不需要清空。
+ 截斷資料表，而非刪除所有資料列。
從資料表刪除資料列不會回收該資料列佔用的空間，直到您執行清空操作為止；不過，截斷資料表會清空資料表和回收磁碟空間，因此不需要清空。或者，捨棄資料表和重新建立它。
+ 截斷或捨棄測試資料表。
如果您因測試目的載入少量的資料列至資料表，在完成之前請勿刪除資料列。而是截斷資料表，並在後續生產載入操作中重新載入這些資料列。
+ 執行深層複製。
如果使用複合排序索引鍵資料表的資料表有大型未排序的區域，深層複製較清空的速度快得多。深層複製會使用會自動重新排序資料表的大量插入來重新建立和重新填入資料表。如果資料表有大型未排序的區域，深層複製較清空的速度快得多。取捨是您不可以在深層複製操作期間進行並行更新，但清空期間卻可以。如需詳細資訊，請參閱[設計查詢的 Amazon Redshift 最佳實務](c_designing-queries-best-practices.md)。
## 減少合併列的數量
如果清空操作必須將新資料列合併至資料表的排序區域，清空所需的時間將隨著資料表變大而增加。您可以透過減少必須合併的資料列數量來改善清空效能。
在清空之前，資料表在資料表的標頭中包含排序的區域，接著是未排序的區域，它會在資料列新增或更新時成長。透過 COPY 操作新增一組資料列時，在新增至資料表尾端的未排序區域時，新的一組資料列會依排序索引鍵排序。新資料列會在其自己的集合內排序，但不會在未排序的區域內排序。
下圖說明兩個後續的 COPY 操作之後的未排序區域，其中的排序索引鍵為 CUSTID。為求簡化，此範例顯示複合排序索引鍵，但相同的原則適用於交錯的排序索引鍵，除了未排序區域的影響大於交錯的資料表。
![\[未排序的資料表，其中保存兩個 COPY 操作的記錄。\]](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/images/vacuum-unsorted-region.png)
清空會以兩個階段還原資料表的排序順序：
1. 將未排序的區域排序為新排序的區域。
第一個階段相當經濟實惠，因為只會重新寫入未排序的區域。如果新排序區域的排序索引鍵值的範圍高於現有範圍，則只需要重新寫入新資料列，清空即完成。例如，如果排序的區域包含 ID 值 1 到 500，而和後續的複製操作會新增大於 500 的索引鍵值，那麼只必須重新寫入未排序的區域。
1. 將新排序的區域與先前排序的區域合併。
如果新排序區域中的索引鍵與排序的區域中的索引鍵重疊，那麼 VACUUM 必須合併資料列。從新排序區域 (最下方的排序索引鍵) 的開頭開始，清空會從將合併的資料列從先前排序的區域和新排序的區域寫入至新的一組區塊。
新排序索引鍵範圍與現有排序索引鍵重疊的程度，決定需要重新寫入先前排序區域的程度。如果未排序的索引鍵分散在現有排序範圍中，清空可能需要重新寫入資料表的現有部分。
下表顯示清空如何排序和合併新增至 CUSTID 為排序索引鍵的資料表的資料列。因為每個複製操作會新增一組新資料列，其具有的索引鍵值與現有索引鍵重疊，幾乎必須重新寫入整個資料表。此表顯示單一的排序和合併，但在實務上，大型的清空包含一系列的遞增排序和合併步驟。
![\[範例資料表上的 VACUUM 操作分為兩個步驟。首先會排序新列，然後與現有列合併。\]](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/images/vacuum-unsorted-region-sort-merge.png)
如果一組新資料列中排序索引鍵的範圍與現有索引鍵的範圍重疊，合併階段的成本會隨著資料表成長，繼續按比例成長至資料表大小，同時排序階段的成本會維持與未排序區域的大小成比例。在這類情況下，合併階段的成本會使得排序階段的成本相形見絀，如下表所示。
![\[圖表中顯示，當新列擁有的排序索引鍵與現有列重疊時，合併階段成本因而更高。\]](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/images/vacuum-example-merge-region-grows.png)
若要判斷資料表重新合併的比例，請在清空操作完成之後查詢 SVV\$1VACUUM\$1SUMMARY。下列查詢顯示在 CUSTSALES 隨著時間變大時，六個後續清空的效果。
```
select * from svv_vacuum_summary
where table_name = 'custsales';
table_name | xid | sort_ | merge_ | elapsed_ | row_ | sortedrow_ | block_ | max_merge_
| | partitions | increments | time | delta | delta | delta | partitions
-----------+------+------------+------------+------------+-------+------------+---------+---------------
custsales | 7072 | 3 | 2 | 143918314 | 0 | 88297472 | 1524 | 47
custsales | 7122 | 3 | 3 | 164157882 | 0 | 88297472 | 772 | 47
custsales | 7212 | 3 | 4 | 187433171 | 0 | 88297472 | 767 | 47
custsales | 7289 | 3 | 4 | 255482945 | 0 | 88297472 | 770 | 47
custsales | 7420 | 3 | 5 | 316583833 | 0 | 88297472 | 769 | 47
custsales | 9007 | 3 | 6 | 306685472 | 0 | 88297472 | 772 | 47
(6 rows)
```
merge\$1increments 資料欄提供針對每個清空操作所合併資料量的指示。如果合併增量的數目超過資料表大小成長比例後續清空的增加，即表示因為現有和新排序的區域重疊，每個清空操作會重新合併資料表中增加數量的資料列。
## 以排序索引鍵順序載入資料
如果使用 COPY 命令以排序索引鍵順序載入您的資料，您可能會降低或甚至免除清空的需求。
當以下各項成立時，COPY 會自動新增新資料列至資料表的排序區域：
+ 資料表使用複合排序索引鍵搭配僅一個排序資料欄。
+ 排序資料欄為 NOT NULL。
+ 資料表完全經過排序或為空白。
+ 所有新資料列的排序順序高於現有資料列，包括標記進行刪除的資料列。在此執行個體中，Amazon Redshift 會使用排序索引鍵的前八個位元組來判斷排序順序。
+ COPY 命令不會觸發特定負載最佳化。載入大量資料時，Amazon Redshift 可能會透過建立新的排序分割區來最佳化效能，而不是將資料列新增至資料表的排序區域。
例如，假設您有一個使用客戶 ID 和時間記錄客戶事件的資料表。如果您依客戶 ID 排序，遞增載入新增的新資料列的排序索引鍵範圍很可能會與現有範圍重疊，如先前的範例所示，導致代價高昂的清空操作。
如果您將您的排序索引鍵設為時間戳記資料欄，您的新資料列將以排序順序附加在資料表結尾，如下表所示，降低或甚至消除清空的需求。
![\[使用時間戳記欄作為排序索引鍵的資料表，收到不需要排序的新記錄。\]](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/images/vacuum-unsorted-region-date-sort.png)
## 使用時間序列資料表來減少儲存的資料
如果您維護資料一段時間，使用一系列資料表，如下圖所述。
![\[包含五個季度資料的五個資料表。最舊的資料表會遭到刪除，讓時間維持在一年。\]](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/images/vacuum-example-unsorted-region-copy-time-series.png)
每次您新增一組資料即建立新的資料表，然後刪除系列中最舊的資料表。您會獲得雙重優勢：
+ 避免刪除資料列的增加成本，因為 DROP TABLE 操作較大量 DELETE 來的更有效。
+ 如果資料表是依時間戳記排序，則不需要清空。如果每個資料表包含一個月的資料，清空將至少必須重新寫入一個月的資料量，即使資料表未依時間戳記排序。
您可以建立 UNION ALL 檢視，供隱藏資料儲存在多個資料表事實的報告查詢使用。如果查詢會依排序索引鍵篩選，查詢規劃器可以有效地略過所有未使用的資料表。UNION ALL 對於其他類型的查詢可能效率較低，因此您應該評估使用該資料表的所有查詢內容中的查詢效能。