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

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

# CTAS 使用須知
<a name="r_CTAS_usage_notes"></a>

## 限制
<a name="r_CTAS_usage_notes-limits"></a>

Amazon Redshift 會依節點類型強制執行每個叢集的資料表數量配額限制。

資料表名稱的字元數上限為 127 個。

單一資料表中可定義的資料欄數目上限為 1,600 個。

## 欄位和資料表屬性的繼承
<a name="r_CTAS_usage_notes-inheritance-of-column-and-table-attributes"></a>

CREATE TABLE AS (CTAS) 資料表不會從其建立的來源資料表繼承限制條件、身分資料欄、預設資料欄值或主索引鍵。

您無法指定 CTAS 資料表的資料欄壓縮編碼。Amazon Redshift 會自動指派壓縮編碼，如下所示：
+ 定義為排序索引鍵的資料欄會有指派的 RAW 壓縮。
+ 定義為 BOOLEAN、REAL、DOUBLE PRECISION、GEOMETRY 或 GEOGRAPHY 資料類型的資料行會有指派的 RAW 壓縮。
+ 定義為 SMALLINT、INTEGER、BIGINT、DECIMAL、DATE、TIME、TIMETZ、TIMESTAMP 或 TIMESTAMPTZ 的資料欄會有指派的 AZ64 壓縮。
+ 定義為 CHAR、VARCHAR 或 VARBYTE 的資料欄會有指派的 LZO 壓縮。

如需詳細資訊，請參閱[壓縮編碼](c_Compression_encodings.md)及[資料類型](c_Supported_data_types.md)。

若要明確指派資料欄編碼，請使用 [CREATE TABLE](r_CREATE_TABLE_NEW.md)。

CTAS 會根據 SELECT 子句的查詢計畫判斷新資料表的分佈樣式和排序索引鍵。

若是複雜的查詢，像是包含聯結、彙總、order by 子句或限制子句的查詢，CTAS 會根據查詢計畫盡可能選擇最佳分佈樣式和排序索引鍵。

**注意**  
為了在大型資料集或複雜查詢上發揮最佳效能，建議您使用一般資料集進行測試。

您可藉由查看查詢計畫來了解查詢最佳化工具選擇哪些資料欄 (如有的話) 來排序和分佈資料，如此經常能夠預測出 CTAS 會選擇哪個分佈索引鍵和排序索引鍵。如果查詢計畫的頂端節點是來自單一資料表的簡單循序掃描 (XN Seq Scan)，則 CTAS 通常會使用來源資料表的分佈樣式和排序索引鍵。若查詢計畫的頂端節點是循序掃描以外的其他項目 (像是 XN Limit、XN Sort、XN HashAggregate 等)，則 CTAS 會根據查詢計畫盡可能選擇最佳分佈樣式和排序索引鍵。

例如，假設您使用下列類型的 SELECT 子句建立五個資料表：
+ 簡單 select 陳述式 
+ 限制子句 
+ 使用 LISTID 的 order by 子句 
+ 使用 QTYSOLD 的 order by 子句 
+ 含有 group by 子句的 SUM 彙總函數。

下列範例顯示每個 CTAS 陳述式的查詢計畫。

```
explain create table sales1_simple as select listid, dateid, qtysold from sales;
                           QUERY PLAN
----------------------------------------------------------------
 XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=8)
(1 row)


explain create table sales2_limit as select listid, dateid, qtysold from sales limit 100;
                              QUERY PLAN
----------------------------------------------------------------------
 XN Limit  (cost=0.00..1.00 rows=100 width=8)
   ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=8)
(2 rows)


explain create table sales3_orderbylistid as select listid, dateid, qtysold from sales order by listid;
                               QUERY PLAN
------------------------------------------------------------------------
 XN Sort  (cost=1000000016724.67..1000000017155.81 rows=172456 width=8)
   Sort Key: listid
   ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=8)
(3 rows)


explain create table sales4_orderbyqty as select listid, dateid, qtysold from sales order by qtysold;
                               QUERY PLAN
------------------------------------------------------------------------
 XN Sort  (cost=1000000016724.67..1000000017155.81 rows=172456 width=8)
   Sort Key: qtysold
   ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=8)
(3 rows)


explain create table sales5_groupby as select listid, dateid, sum(qtysold) from sales group by listid, dateid;
                              QUERY PLAN
----------------------------------------------------------------------
 XN HashAggregate  (cost=3017.98..3226.75 rows=83509 width=8)
   ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=8)
(2 rows)
```

若要檢視每個資料表的分佈索引鍵和排序索引鍵，請查詢 PG\$1TABLE\$1DEF 系統目錄資料表，如下所示。

```
select * from pg_table_def where tablename like 'sales%';

      tablename       |   column   | distkey | sortkey
----------------------+------------+---------+---------
 sales                | salesid    | f       |       0
 sales                | listid     | t       |       0
 sales                | sellerid   | f       |       0
 sales                | buyerid    | f       |       0
 sales                | eventid    | f       |       0
 sales                | dateid     | f       |       1
 sales                | qtysold    | f       |       0
 sales                | pricepaid  | f       |       0
 sales                | commission | f       |       0
 sales                | saletime   | f       |       0
 sales1_simple        | listid     | t       |       0
 sales1_simple        | dateid     | f       |       1
 sales1_simple        | qtysold    | f       |       0
 sales2_limit         | listid     | f       |       0
 sales2_limit         | dateid     | f       |       0
 sales2_limit         | qtysold    | f       |       0
 sales3_orderbylistid | listid     | t       |       1
 sales3_orderbylistid | dateid     | f       |       0
 sales3_orderbylistid | qtysold    | f       |       0
 sales4_orderbyqty    | listid     | t       |       0
 sales4_orderbyqty    | dateid     | f       |       0
 sales4_orderbyqty    | qtysold    | f       |       1
 sales5_groupby       | listid     | f       |       0
 sales5_groupby       | dateid     | f       |       0
 sales5_groupby       | sum        | f       |       0
```

下表顯示結果摘要。為了簡化起見，我們省略了說明計畫中的成本、資料列和寬度詳細資訊。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/redshift/latest/dg/r_CTAS_usage_notes.html)

您可以在 CTAS 陳述式中明確指定分佈樣式和排序索引鍵。例如，以下陳述式會使用 EVEN 分佈建立資料表，並指定 SALESID 做為排序索引鍵。

```
create table sales_disteven
diststyle even
sortkey (salesid)
as
select eventid, venueid, dateid, eventname
from event;
```

## 壓縮編碼
<a name="r_CTAS_usage_notes_encoding"></a>

ENCODE AUTO 會用來作為資料表的預設值。Amazon Redshift 會自動管理資料表中所有資料欄的壓縮編碼。

## 傳入資料的分佈
<a name="r_CTAS_usage_notes-distribution-of-incoming-data"></a>

當傳入資料的雜湊分佈機制與目標資料表的機制相同時，不需要在資料載入時實際分佈資料。例如，如果新資料表設定了分佈索引鍵，而且要從另一個分佈在相同索引鍵資料欄上的資料表插入資料，則會使用相同的節點和分割就地載入資料。不過，如果來源和目標資料表都設定為 EVEN 分佈，則資料會重新分佈至目標資料表中。

## 自動 ANALYZE 操作
<a name="r_CTAS_usage_notes-automatic-analyze-operations"></a>

Amazon Redshift 會自動分析您使用 CTAS 命令建立的資料表。您不需要在初次建立這些資料表時，對其執行 ANALYZE 命令。若您修改這些資料表，則應依照與其他資料表相同的方式進行分析。