

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

Amazon Redshift 可以在背景中自動排序及在資料表上執行 VACUUM DELETE 操作。如要在載入或一系列的累加式更新之後清理資料表，您也可以對整個資料庫或個別資料表執行 [VACUUM](r_VACUUM_command.md) 命令。

**注意**  
只有具有必要資料表權限的使用者才能有效地清除資料表。若 VACUUM 執行時沒有必要的資料表權限，操作仍會成功完成，但不會有任何作用。如需有效執行 VACUUM 的有效資料表權限清單，請參閱 [VACUUM](r_VACUUM_command.md)。  
因此，我們建議視需要清空個別資料表。我們也建議使用此方法，因為清空整個資料庫可能會是相當耗費資源的操作。

## 自動資料表排序
<a name="automatic-table-sort"></a>

Amazon Redshift 會在背景中自動排序資料，以依據其排序索引鍵的順序維護資料表資料。Amazon Redshift 會追蹤您的掃描查詢，以判斷資料表中的哪些區段適合排序。Amazon Redshift 也會追蹤並行擴展叢集的掃描查詢。對於使用 Amazon Redshift 資料共用的多叢集架構，Amazon Redshift 也會追蹤來自資料網格中取用者叢集/工作群組的掃描查詢，包括不同區域的叢集/工作群組。主要叢集、並行擴展叢集和取用者叢集的掃描統計資料會彙總，以判斷資料表的哪些區段將受益於排序。

取決於系統上的載入，Amazon Redshift 會自動啟動排序。這種自動排序能減少執行 VACUUM 命令以將資料保持在排序索引鍵順序的需求。如果您需要資料完全依照排序索引鍵的順序排序 (例如在大型資料載入後)，您仍然可以手動執行 VACUUM 命令。如要判斷您的資料表是否能從執行 VACUUM SORT 中獲益，請監控 [SVV\_TABLE\_INFO](r_SVV_TABLE_INFO.md) 中的 `vacuum_sort_benefit` 資料行。

Amazon Redshift 追蹤會掃描每個資料表上使用排序索引鍵的查詢。Amazon Redshift 會估計掃描及篩選每個資料表資料獲得改善的最大百分比 (如果資料表已完全排序的話)。您可以在 [SVV\_TABLE\_INFO](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 中獲益。

## 自動清空刪除
<a name="automatic-table-delete"></a>

當您執行刪除時，資料列會標示為要刪除，但不會移除。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 頻率
<a name="vacuum-frequency"></a>

您應該根據需求時常進行清空，才能保有一致的查詢效能。判斷執行您的 VACUUM 命令的頻率時，請考慮這些因素：
+ 在您預期叢集上只有最少量活動的時段期間，例如傍晚或指定的資料庫管理時段期間執行 VACUUM。
+ 在維護時段外執行 VACUUM 命令。如需詳細資訊，請參閱[排程維護時段](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html)。
+ 大量未排序的區域會造成較長的清空時間。如果您延遲清空，清空會耗費更長時間，因為必須重新整理更多資料。
+ VACUUM 為 I/O 密集的操作，因此，清空完成所需的時間愈長，對您的叢集執行的並行查詢和其他資料庫操作造成的影響愈大。
+ 對於使用交錯排序的資料表，VACUUM 需要較長的時間。如要評估是否必須重新排序交錯的資料表，請查詢 [SVV\_INTERLEAVED\_COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) 檢視。

## 排序階段和合併階段
<a name="vacuum-stages"></a>

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)。

## 清空閾值
<a name="vacuum-sort-threshold"></a>

根據預設，若資料表中超過 95% 的資料列已排序，則 VACUUM 會略過資料表的排序階段。略過排序階段可大幅改善 VACUUM 的效能。若要變更單一資料表的預設排序閾值，在執行 VACUUM 命令時，請包含資料表名稱和 TO *閾值* PERCENT 參數。

## 清空類型
<a name="vacuum-types"></a>

如需不同清空類型的詳細資訊，請參閱 [VACUUM](r_VACUUM_command.md)。