

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

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# CREATE TABLE AS
<a name="r_CREATE_TABLE_AS"></a>

**Topics**
+ [語法](#r_CREATE_TABLE_AS-synopsis)
+ [Parameters](#r_CREATE_TABLE_AS-parameters)
+ [CTAS 使用須知](r_CTAS_usage_notes.md)
+ [CTAS 範例](r_CTAS_examples.md)

根據查詢建立新資料表。此資料表的擁有者是發出命令的使用者。

載入的新資料表包含命令中的查詢所定義的資料。資料表資料欄的名稱和資料類型會與查詢的輸出資料欄相關聯。CREATE TABLE AS (CTAS) 命令會建立新資料表，並評估查詢以載入新資料表。

## 語法
<a name="r_CREATE_TABLE_AS-synopsis"></a>

```
CREATE [ [ LOCAL ] { TEMPORARY | TEMP } ]
TABLE table_name
[ ( column_name [, ... ] ) ]
[ BACKUP { YES | NO } ]
[ table_attributes ]
AS query

where table_attributes are:
[ DISTSTYLE { AUTO | EVEN | ALL | KEY } ]
[ DISTKEY( distkey_identifier ) ]
[ [ COMPOUND | INTERLEAVED ] SORTKEY( column_name [, ...] ) ]
```

## Parameters
<a name="r_CREATE_TABLE_AS-parameters"></a>

LOCAL   
雖然陳述式中可接受此選用關鍵字，但是在 Amazon Redshift 中沒有作用。

TEMPORARY \| TEMP   
建立臨時資料表。臨時資料表會在其建立所在的工作階段結束時自動捨棄。

 *table\_name*   
要建立的資料表名稱。  
若您指定 '\#' 開頭的資料表名稱，所建立的資料表會是臨時資料表。例如：  

```
create table #newtable (id) as select * from oldtable;
```
資料表名稱長度上限為 127 個位元組；超過此長度的名稱會截斷至 127 個位元組。Amazon Redshift 會依節點類型強制執行每個叢集的資料表數量配額限制。資料表名稱也可透過資料庫和結構描述名稱來限定，如下表所示。  

```
create table tickit.public.test (c1) as select * from oldtable;
```
在此範例中，`tickit` 是資料庫名稱，而 `public` 是結構描述名稱。如果資料庫或結構描述不存在，則陳述式會傳回錯誤。  
若提供結構描述名稱，則會在該結構描述中建立新資料表 (假設建立者具有存取結構描述的權限)。資料表名稱對於該結構描述來說必須是唯一的。如果未指定結構描述，則會使用目前資料庫結構描述建立資料表。如果您要建立臨時資料表，就不能指定結構描述名稱，因為臨時資料表會採用特殊結構描述。  
若臨時資料表是在不同的工作階段中建立的話，則允許在同一個資料庫中同時有多個同名的臨時資料表存在。這些資料表會指派至不同的結構描述。

 *column\_name*   
新資料表中資料欄的名稱。若未提供任何資料欄名稱，則會採用查詢的輸出資料欄名稱做為資料欄名稱。表達式會使用預設資料欄名稱。如需有效名稱的相關資訊，請參閱 [名稱與識別碼](r_names.md)。

BACKUP \{ YES \| NO \}   
此子句會指定資料表是否應包含在自動化和手動叢集快照中。  
若是像臨時資料表這類不會包含重要資料的資料表，指定 BACKUP NO 可以在建立快照以及從快照還原時節省處理時間，並減少 Amazon Simple Storage Service 上的儲存空間。BACKUP NO 設定對於將資料自動複寫到叢集內其他節點的操作並無影響，因此指定了 BACKUP NO 的資料表會在節點發生故障時還原。預設值為 BACKUP YES。  
RA3 佈建叢集和 Amazon Redshift Serverless 工作群組不支援無備份資料表。在 RA3 叢集或無伺服器工作群組中標記為無備份的資料表會視為永久資料表，且在拍攝快照時一律會備份，並一律在從快照還原時還原。為了避免無備份資料表的快照成本，請在拍攝快照之前截斷這些資料表。

DISTSTYLE \{ AUTO \| EVEN \| KEY \| ALL \}  
定義整個資料表的資料分佈樣式的關鍵字。Amazon Redshift 會根據資料表上指定的分佈樣式，將資料表的資料列分散到運算節點。預設值為 DISTSTYLE AUTO。  
您為資料表選取的分佈樣式會影響資料庫的整體效能。如需詳細資訊，請參閱[分配資料以實現查詢最佳化](t_Distributing_data.md)。  
+ AUTO：Amazon Redshift 會根據資料表資料來指派最佳分佈樣式。若要檢視套用至資料表的分佈樣式，請查詢 PG\_CLASS 系統目錄資料表。如需詳細資訊，請參閱[檢視分佈樣式](viewing-distribution-styles.md)。
+ EVEN：資料表中的資料會採循環分佈的方式，均勻分配到叢集中的各個節點。資料列 ID 會用來決定分佈，並且將大致相同的資料列數分佈到每個節點。這是預設分佈方法。
+ KEY：資料是依 DISTKEY 資料欄中的值分佈。當您將聯結資料表的聯結資料欄設定為分佈索引鍵時，兩個資料表的聯結資料列會在運算節點上並存。資料並存時，最佳化工具就能更有效率地執行聯結。若您指定 DISTSTYLE KEY，則必須命名一個 DISTKEY 資料欄。
+  ALL：整個資料表的副本分佈至每個節點。此分佈樣式可確保每個節點上都有任何聯結所需的所有資料列，但儲存空間的需求也會倍增，並且會增加資料表的負載和維護次數。ALL 分佈在 KEY 分佈不適用的情況下搭配特定維度資料表使用時，可改善執行時間，但必須在效能提升與維護成本之間進行權衡。

DISTKEY (*column*)  
指定分佈索引鍵的資料欄名稱或位置編號。使用資料表的選用資料欄清單中所指定的名稱，或是查詢的選取清單中指定的名稱。或者，使用位置編號，其中選取的第一個資料欄為 1、第二個為 2，以此類推。資料表中只能有一個資料欄是分佈索引鍵：  
+ 如果您將資料欄宣告為 DISTKEY 資料欄，則 DISTSTYLE 必須設定為 KEY，或完全不設定。
+ 如果您未宣告 DISTKEY 資料欄，則可以將 DISTSTYLE 設定為 EVEN。
+ 如果您不指定 DISTKEY 或 DISTSTYLE，則 CTAS 會根據 SELECT 子句的查詢計畫判斷新資料表的分佈樣式。如需詳細資訊，請參閱[欄位和資料表屬性的繼承](r_CTAS_usage_notes.md#r_CTAS_usage_notes-inheritance-of-column-and-table-attributes)。
您可以將同一個資料欄定義為分佈索引鍵和排序索引鍵；此方法主要目的是在所指的資料欄要與查詢中的資料欄聯結時加速聯結。

[ COMPOUND \| INTERLEAVED ] SORTKEY ( *column\_name* [, ... ] )  
指定資料表的一個或多個排序索引鍵。當資料載入資料表時，資料會依指定為排序索引鍵的資料欄排序。  
您也可以選擇指定 COMPOUND 或 INTERLEAVED 排序樣式。預設值為 COMPOUND。如需詳細資訊，請參閱[排序索引鍵](t_Sorting_data.md)。  
您最多可為每個資料表定義 400 個 COMPOUND SORTKEY 資料欄或 8 個 INTERLEAVED SORTKEY 資料欄。  
如果您不指定 SORTKEY，則 CTAS 會根據 SELECT 子句的查詢計畫判斷新資料表的排序索引鍵。如需詳細資訊，請參閱[欄位和資料表屬性的繼承](r_CTAS_usage_notes.md#r_CTAS_usage_notes-inheritance-of-column-and-table-attributes)。    
COMPOUND  
指定使用複合索引鍵排序資料，該索引鍵是由列出的所有資料欄組成，並依其列出順序排列。當查詢依據排序資料欄的順序掃描資料列時，複合排序索引鍵最實用。當查詢依賴次要排序資料欄時，使用複合索引鍵排序的效能優勢就會降低。您最多可為每個資料表定義 400 個 COMPOUND SORTKEY 資料欄。  
INTERLEAVED  
指定使用交錯排序索引鍵排序資料。最多可以為交錯排序索引鍵指定八個資料欄。  
交錯排序索引鍵對排序索引鍵中的每個資料欄 (或資料欄子集) 都提供相等的權重，所以查詢不會取決於排序索引鍵中資料欄的順序。當查詢使用一個或多個次要排序資料欄時，交錯排序可大幅改善查詢效能。交錯排序在執行資料載入和清空操作時，會產生很少的額外負荷成本，

AS *query*   
Amazon Redshift 支援的任何查詢 (SELECT 陳述式)。