Redshift 查詢調校、COPY 與 UNLOAD 構成了每個生產環境中 Redshift 工作負載的營運骨幹。在 DEA-C01 考試中，大約每五題網域 3 (Domain 3) 的題目中就有一題涉及這些命令。考試不僅會問「COPY 的作用是什麼」，還會詢問場景問題，例如「從 10 TB S3 前綴執行 COPY 作業需要 8 小時，如何做最大的改進」或「三個月未執行 VACUUM 且查詢變慢，正確的 VACUUM 模式是什麼」。來自 Tutorials Dojo、Cesar Cordoba 的 AWS in Plain English 系列以及 Laura Galera 的開源筆記等社群學習指南都指出了同樣的問題：考生知道這些命令的存在，但在考試場景下無法選擇正確的選項或順序。
本指南旨在將 Redshift 的營運命令轉化為工程實踐記憶。內容涵蓋 COPY 命令與「檔案數量等於切片 (slice) 倍數」的平行處理規則、用於增量載入的資訊清單 (manifest) 檔案、COMPUPDATE 與 STATUPDATE、UNLOAD 命令與 PARALLEL ON、VACUUM 的四種模式、用於規劃器統計資訊的 ANALYZE、自動與手動 WLM 佇列、用於讀取分散偏斜 (distribution skew) 與排序鍵遺漏的 EXPLAIN 計劃、排序鍵與分散鍵的選擇、用於突發讀取容量的並行調整 (Concurrency Scaling)，以及讓大多數考生掉入陷阱的經典 COPY-UNLOAD-VACUUM 考試陷阱。
COPY — 從 S3 進行平行批次載入
COPY 是營運 Redshift 中最重要的單一命令。每個將 S3 資料匯入 Redshift 的生產資料管道都是由 COPY 驅動的。
COPY 語法與來源
COPY target_table FROM 's3://bucket/prefix/' IAM_ROLE 'arn:aws:iam::account:role/RedshiftLoad' FORMAT AS PARQUET; — 這是典型的語法形式。來源可以是 S3 (最常見)、DynamoDB、EMR、具備 SSH 存取權限的遠端主機，或是透過聯合載入 (federated load) 的另一個 Redshift 叢集。IAM 角色連接到叢集，並授予 S3 讀取權限以及選用的 KMS 解密權限；雖然支援使用者憑證 COPY，但在生產環境中不建議使用。
支援的格式
原生格式包括：CSV、JSON、Avro、ORC、Parquet、純文字 (TEXT)。Parquet 與 ORC 是單欄式 (columnar) 格式，載入速度最快，且能與 Glue Data Catalog 整合。CSV 需要 DELIMITER 與 QUOTE 選項；JSON 需要自動對應或 JSONPaths 檔案。從串流 Avro 生產者載入時，建議使用 Avro，因為其結構描述演進 (schema evolution) 語義相符。
平行處理規則 — 檔案數量等於切片計數的倍數
Redshift 的平行處理受限於來源前綴中的檔案數量。叢集具有固定的切片 (slice，運算單位) 總數 — 例如，一個 8 節點的 ra3.4xlarge 叢集共有 16 個切片，每個節點 2 個。COPY 會將每個輸入檔案分配給剛好一個切片。如果來源前綴有 16 個檔案，所有切片都會平行載入。如果來源只有 1 個巨大檔案，則只有 1 個切片載入，另外 15 個切片處於閒置狀態 — 載入速度會比必要的速度慢 16 倍。經驗法則：將來源資料分割成等於叢集切片計數倍數的檔案數量，理想情況下，壓縮後的每個檔案大小在 1 MB 到 1 GB 之間。
資訊清單 (Manifest) 檔案
資訊清單是一個 JSON 檔案，列出了要載入的確切 S3 金鑰 (key) — 當來源前綴包含不應全部載入的檔案，或需要原子地載入一組已知檔案 (避免在新檔案於載入期間到達時產生部分檔案競合) 時使用。參考：COPY ... FROM 's3://bucket/manifest.json' MANIFEST;。對於每日增量載入，資訊清單模式是推薦的方法，因為它使輸入集具有確定性。
COMPUPDATE 與 STATUPDATE
COMPUPDATE ON (空目標資料表的預設值) 會告知 COPY 分析輸入樣本，並為每欄選擇最佳的壓縮編碼 (compression encoding)。第一次載入後，編碼會被固定，後續載入應選擇 COMPUPDATE OFF 以避免重新分析。STATUPDATE ON (空資料表的預設值) 在載入期間為查詢規劃器更新資料表統計資訊。在初始批次載入後，後續 COPY 應設置 STATUPDATE OFF，並在受控時間單獨執行 ANALYZE — 內置的統計資訊更新會顯著延長 COPY 持續時間。
從其他來源 COPY
COPY 可以直接從 DynamoDB 資料表 (全表讀取，對大型資料表來說很昂貴)、從 EMR HDFS (用於舊版遷移) 以及透過帶有 SSH 資訊清單的 FROM 子句從另一個 Redshift 叢集讀取。對於持續的複寫模式，AWS DMS 或聯合查詢 (Federated Query) 通常比定期執行的 DynamoDB COPY 作業更好。
在載入大型資料集之前，務必將 COPY 來源資料分割成等於叢集切片計數倍數的檔案數量。 一個 100 GB 的單一檔案只會在一個切片上載入，而其他所有切片都會閒置 — 一個擁有 16 個切片的叢集載入一個檔案的速度，比同一個叢集載入 16 個大小均勻檔案的速度慢 16 倍。補救措施：執行上游的 Glue ETL 或 EMR 步驟，將來源寫入為分割成多個輸出檔案的 Parquet，或在從另一個 Redshift 叢集預備到 S3 時，使用 UNLOAD 上的 MAXFILESIZE 參數來控制輸出檔案數量。對於 DEA-C01 關於 COPY 緩慢的考試場景，答案很少是「調整叢集規模」 — 答案通常是「拆分來源檔案」。將此規則與後續載入時的 COMPUPDATE OFF 和 STATUPDATE OFF 搭配使用，以避免重新分析成本。
UNLOAD — 向 S3 進行平行匯出
UNLOAD 是 COPY 的反向操作 — 它將查詢結果從 Redshift 平行匯出到 S3。
UNLOAD 語法
UNLOAD ('SELECT * FROM table WHERE date=current_date') TO 's3://bucket/prefix/' IAM_ROLE 'arn:...' FORMAT AS PARQUET PARALLEL ON; — SELECT 在叢集上執行，結果分佈在各個切片中，每個切片將其分擔的部分作為單獨的檔案寫入 S3。
PARALLEL ON 與 PARALLEL OFF
PARALLEL ON (預設值) 為每個切片寫入一個或多個檔案，以實現最大處理量 — 對於大型匯出最快，但會產生許多輸出檔案。PARALLEL OFF 寫入單個排序後的輸出檔案，代價是除了一個切片外所有切片都處於閒置狀態 — 僅適用於下游工具無法處理多個檔案的小型擷取。考試中常將其設為「1 TB 資料最快匯出」的場景；PARALLEL ON 是正確答案。
格式選項
UNLOAD 支援 CSV、JSON、Parquet 與 TEXT。Parquet 是後續 Athena 或 Spectrum 讀取的推薦目標格式 — 當稍後查詢匯出的資料時，可以套用單欄剪裁 (column pruning) 與述詞下推 (predicate pushdown)。JSON 適用於下游 NoSQL 儲存；CSV 適用於舊版系統。
MAXFILESIZE 與 ALLOWOVERWRITE
MAXFILESIZE 100 MB 將每個輸出檔案的大小限制在指定值 — 如果切片分擔的部分超過上限，則會寫入多個檔案。這是對偏好已知檔案大小範圍的下游取用者的正確控制方式。ALLOWOVERWRITE 允許寫入已包含檔案的 S3 前綴；若不使用此選項，如果目標前綴不為空，UNLOAD 將失敗。
UNLOAD 加密
ENCRYPTED 使用指定的金鑰並透過 SSE-KMS 寫入輸出。連接到叢集的 IAM 角色必須對該金鑰具有 kms:GenerateDataKey 權限。對於受合規性限制的工作負載，這是強制性的；預設行為繼承儲存貯體的預設加密。
VACUUM — 回收空間與重新排序
VACUUM 是維護命令，用於從刪除的資料列中回收磁碟空間，並對未排序的區域進行重新排序。考試會測試 VACUUM 模式以及何時使用每一種模式。
為什麼需要 VACUUM
Redshift 是單欄式導向且主要採用附加 (append-mostly) 模式。DELETE 與 UPDATE 不會物理刪除資料列 — 它們只是將其標記為已刪除。超出排序區域的插入會累積在未排序區域中。如果不執行 VACUUM，已刪除的資料列將繼續佔用磁碟，且未排序區域會增長，從而降低查詢效能，因為規劃器在每次範圍查詢時都必須掃描未排序資料。
四種模式
VACUUM SORT ONLY 將未排序區域重新排序到排序區域中，但不回收已刪除資料列的空間。當僅需重新排序時，此模式較快。
VACUUM DELETE ONLY 回收已刪除資料列的空間，但不重新排序。適用於執行大量 DELETE 後且排序順序不受影響的情況。
VACUUM FULL (若未指定模式則為預設值) 同時執行兩者 — 重新排序與回收空間。速度最慢但最徹底；屬於典型的定期維護。
VACUUM REINDEX 在發生大量資料變更後重建交錯排序鍵 (interleaved sort key) 索引。僅適用於具有 INTERLEAVED 排序鍵的資料表；具有 COMPOUND (複合) 排序鍵的資料表不需要 REINDEX。
RA3 上的自動 VACUUM
RA3 節點在背景執行自動 VACUUM 與 ANALYZE — Redshift 會在低負載期間排定維護。這並不能完全消除手動 VACUUM 的需求，但減輕了典型工作負載的營運負擔。DC2 與較早期的節點類型不會執行自動 VACUUM，需要明確排程。考試常將其設為「RA3 上尚未執行 VACUUM」的場景；答案通常涉及理解 RA3 自動化減輕了需求，但並未完全消除。
Boost 模式與資源配置
VACUUM ... BOOST 為 VACUUM 作業配置更多叢集資源，完成速度更快，但會與並行查詢產生爭用。用於非尖峰時段的維護期間。
VACUUM REINDEX 僅對 INTERLEAVED 排序鍵是必要的，對 COMPOUND 排序鍵則不然，且大多數 Redshift 資料表應使用 COMPOUND。 無需使用 INTERLEAVED 排序鍵的工程師既要支付較慢的載入成本，又要承擔定期的 REINDEX 成本 — 只有在查詢模式對多個具有相似選擇性 (selectivity) 的排序欄位進行過濾時，INTERLEAVED 才是正確的，這是一個狹隘的案例。DEA-C01 考試常將此作為排序鍵選擇或維護問題 — 如果場景描述對三個欄位進行均等權重過濾並詢問 VACUUM，則 INTERLEAVED 加上 REINDEX 可能是正確的；如果場景是典型的按日期分割的事實資料表且主要按日期查詢，則使用 COMPOUND 排序鍵且無需 REINDEX 才是正確答案。
ANALYZE — 更新規劃器統計資訊
ANALYZE 收集欄位層級的統計資訊，查詢規劃器使用這些資訊來選擇聯結順序、分散策略和計劃形狀。如果沒有最新的統計資訊，規劃器可能會選擇災難性的錯誤計劃。
何時執行 ANALYZE
在發生大量資料變更 (超過 10% 的資料列新增或修改)、結構描述變更後，或對高寫入頻率的資料表進行定期排程後執行 ANALYZE。RA3 節點會在背景自動執行 ANALYZE，但在重大載入後執行明確的 ANALYZE 仍然是適當的。
ANALYZE 述詞欄位 (Predicate Columns)
ANALYZE table_name PREDICATE COLUMNS 僅分析 WHERE、JOIN 與 GROUP BY 子句中使用的欄位 — 這些欄位才是實際驅動計劃選擇的關鍵。這比全表 ANALYZE 更快，建議用於寬表 (wide tables)。
統計資訊失效閾值 (Statistics Off Threshold)
系統資料表 STV_TBL_PERM 有一個 stats_off 欄位，報告自上次 ANALYZE 以來變更的資料列百分比。stats_off 超過 10% 的資料表是 ANALYZE 的候選對象。
WLM — 工作負載管理
WLM 是隔離查詢工作負載的佇列與並行模型。
自動 WLM (Automatic WLM)
自 2018 年起的預設值 — Redshift 根據觀察到的工作負載動態配置記憶體與並行度。建議用於幾乎所有工作負載；它的適應速度比人工調校手動佇列更快。考試會將自動 WLM 作為推薦的基準。
手動 WLM (Manual WLM)
靜態佇列配置，具有明確的記憶體百分比和每個佇列的並行度。當特定佇列必須擁有保證資源時使用 — 例如，關鍵儀表板佇列不能被分析師的臨時查詢耗盡資源。手動 WLM 要求操作員預測工作負載組合；配置錯誤會導致利用率不足或資源匱乏。
查詢優先級與短查詢加速 (Short Query Acceleration)
在自動 WLM 中，可以為查詢分配優先級 (HIGHEST、HIGH、NORMAL、LOW、LOWEST)。短查詢加速 (SQA) 是一種內建優化，可快速處理規劃器預測執行速度很快的查詢，從而繞過佇列爭用。
並行調整 (Concurrency Scaling)
當佇列的並行限制達到時，並行調整會自動提供額外的叢集容量以吸收突發負載。唯讀查詢符合資格。每個叢集每執行 24 小時主叢集運作時間即可獲得一小時免費的並行調整點數；超過部分按秒計費。考試常將其設為「不調整規模即可獲得讀取查詢的突發容量」場景。
在讀取密集型工作負載上啟用並行調整 (Concurrency Scaling)，以吸收突發負載而無需永久調整叢集規模。 典型模式：平日工作時段的查詢率是夜晚和週末的 5 倍。按尖峰需求調整主叢集規模是浪費的 (每日 5 倍負載卻需支付 5 倍成本)；按平均需求調整規模則意味著尖峰查詢會排隊。並行調整解決了這個問題 — 主叢集按平均值調整規模，尖峰突發由臨時擴展叢集按秒計費處理。免費點數 (每 24 小時主叢集運作時間贈送一小時) 通常能以零額外成本涵蓋正常的尖峰模式。在 WLM 的佇列層級配置擴展。對於關於變動讀取負載或「使用者抱怨在工作時間等待」的 DEA-C01 考試場景，並行調整是正確答案；調整叢集規模則是一個干擾項。
EXPLAIN — 讀取查詢計劃
在 SELECT 前加上 EXPLAIN 會傳回查詢計劃而不執行 — 這是工程師主要的偵錯工具。
計劃運算子 (Plan Operators)
Seq Scan 執行全表掃描 — 對於未過濾的讀取是預期的，但當對排序鍵進行 WHERE 過濾本應執行範圍掃描時，這就是問題。Index Scan 透過排序鍵範圍進行讀取 — 這是好的。Hash Join、Merge Join、Nested Loop 是三種聯結演算法；在大型資料表上使用 nested loop 是一個警訊。資料移動列上的 DS_BCAST_INNER (廣播內部資料表) 與 DS_DIST_BOTH (重新分散兩個資料表) 表示聯結正在跨網路進行，因為分散鍵不一致 — 這是典型的效能臭蟲。
分散偏斜 (Distribution Skew)
當一個切片接收到的資料列遠多於其他切片時，該切片就會成為瓶頸。系統檢視 SVV_TABLE_INFO 報告 skew_rows (最大值與平均值的比率) — 超過 4.0 的值表示明顯偏斜。這通常由 DISTSTYLE KEY 搭配低基數 (low-cardinality) 分散欄位或鍵中包含許多 NULL 值引起。修正方法：選擇基數較高的欄位、切換至 DISTSTYLE EVEN 或 DISTSTYLE AUTO。
排序鍵遺漏 (Sort Key Misses)
計劃顯示 Seq Scan 帶有一個過濾條件，而該條件本應是排序鍵範圍掃描。原因：對排序欄位套用了函式 (WHERE DATE_TRUNC('day', ts) = '2026-05-02' 不會使用 ts 上的排序鍵；而 WHERE ts BETWEEN '2026-05-02' AND '2026-05-03' 則會)，或者該欄位根本未被選為排序鍵。
排序鍵與分散鍵
這兩個資料表層級的選擇對查詢效能的驅動作用超過任何其他營運設定。
分散樣式 (Distribution Styles)
DISTSTYLE KEY 按欄位的雜湊值分散資料列 — 最適用於聯結頻繁且聯結資料表共享分散欄位的工作負載。DISTSTYLE EVEN 在各個切片之間以輪詢 (round-robin) 方式分散資料列 — 分散均勻，但無協同放置 (co-location) 優勢。DISTSTYLE ALL 在每個切片上複製完整資料表 — 最適用於與大型事實資料表聯結的小型維度表。DISTSTYLE AUTO 是預設值，由 Redshift 決定；對於生產工作負載，明確選擇通常優於 AUTO。
排序鍵 (Sort Keys)
COMPOUND 排序鍵 (預設值) 按列出的欄位順序對資料列進行排序 — 當查詢對領先欄位 (leading columns) 進行過濾時效果最好。INTERLEAVED 排序鍵對鍵中的每個欄位給予均等權重 — 僅當查詢以相似頻率對不同排序欄位進行過濾時才有用。INTERLEAVED 很少是正確答案，因為它的載入速度較慢、需要 REINDEX，且在實踐中很少優於 COMPOUND。
Redshift Advisor
Redshift Advisor (在主控台中) 會自動偵測次佳的排序鍵、分散鍵與壓縮編碼選擇，並根據觀察到的查詢模式建議變更。合理的節奏是：每月執行一次 Advisor，並在影響最大的資料表上套用建議。
非強制限制 — 一個肯定的陷阱
Redshift 支援 PRIMARY KEY、UNIQUE 與 FOREIGN KEY 語法，但這些限制僅作為中繼資料 — Redshift 在插入時不會強制執行它們。
這是什麼意思
向聲明了 PRIMARY KEY (id) 的資料表執行 COPY 時，不會拒絕重複的 id 值。限制的存在是為了查詢規劃器 — 知道 id 是唯一的有助於規劃器在某些計劃中跳過重複資料刪除步驟。但資料完整性契約是工程師的責任，需在上游 ETL 中強制執行。
為什麼這個陷阱反覆出現
具有 PostgreSQL 或 SQL Server 背景的工程師會假設限制強制執行是內建的。DEA-C01 考試會透過場景測試這一點，例如「ETL 作業載入了 10% 的重複資料且儀表板計數錯誤，原因為何」 — 答案是 Redshift 接受了重複資料，因為限制並未強制執行。修正方法是在 ETL 中進行上游去重，或在下游使用 COUNT(DISTINCT) 進行聚合。
白話文解釋 Redshift Query Tuning, COPY And UNLOAD
三個具體的比喻讓 Redshift 的營運命令變得直觀。
比喻 1 — 郵件分揀中心
想像一個擁有 16 個平行運作的分揀站 (切片) 的郵件分揀中心。一輛載有 10 噸郵件 (COPY 來源) 的卡車到達。如果郵件裝在 16 個均勻分揀的袋子中，每個分揀站都會平行工作，整車郵件在一小時內就能處理完畢。如果郵件是以 1 個巨大的堆堆放的，則只有 1 個分揀站可以進行分揀，而另外 15 個站只能觀看 — 體積相同，時間卻是 16 倍。COPY 平行處理規則正是如此：將來源拆分成等於切片計數倍數的檔案數量。資訊清單檔案就像袋子上的標籤，告知調度員確切要從卡車上取下哪些袋子 — 防止在班次中途有新袋子到達時意外發生重複處理。UNLOAD 是反向過程：在一天結束時，分揀中心將向外的郵件匯出到 16 個袋子中，以便下一輛卡車能高效運載。VACUUM 是夜班清潔小組，負責撿起丟棄的信封 (已刪除的資料列)、重新填滿半滿的箱子 (重新排序未排序區域)，並為明天的地板做準備。如果一個月不進行夜間清潔，地板就會雜亂，分揀變慢，每日處理量也會下降。
比喻 2 — 共享爐灶的餐廳預備廚房
想像一家餐廳，16 名線上廚師共享一個廚房 (叢集)，每份訂單都經過相同的預備流程。餐廳經理就是 WLM — 決定在任何時刻應有多少廚師負責開胃菜 (佇列 1)、主菜 (佇列 2) 和甜點 (佇列 3)。自動 WLM 是一位聰明的經理，他會觀察佇列長度並動態重新分配廚師；手動 WLM 則是固定的排班表，無論實際需求如何，都規定「主菜始終有 4 名廚師，開胃菜始終有 4 名廚師」。並行調整是撥給隔壁餐飲外燴公司的電話線 — 當晚餐尖峰需求超過容量時，外燴公司會派臨時廚師處理溢出的訂單，按小時計費。每天的第一個小時是免費的 (點數)。EXPLAIN 是菜單工程師在菜餚烹飪前閱讀食譜，預測「這道菜需要煎烤站，而該站正處於瓶頸」 — 讓主廚在服務前重新設計食譜。分散偏斜是一名廚師收到了所有的開胃菜訂單，而其他廚師則閒置；修正方法是在廚師之間重新分配顧客 (變更分散鍵) 或讓每名廚師輪流處理每道菜 (DISTSTYLE EVEN)。
比喻 3 — 帶有車道和維修的高速公路收費系統
想像一條擁有多個車道和收費站的高速公路。COPY 是入口匝道 — 車輛 (資料列) 從預備場 (S3) 流入，平行度由預備場開啟了多少個入口車道決定。一輛巨大的卡車 (一個大檔案) 會阻塞 16 個車道中的 15 個。UNLOAD 是出口匝道 — 車輛平行離開高速公路前往預備場。VACUUM 是道路維修小組，負責清理事故殘骸 (已刪除的資料列) 並重新粉刷車道線 (重新排序)。如果一個月不派維修小組，交通就會變慢。ANALYZE 是交通調查團隊，負責計算每個路口的車流量 — 沒有調查，規劃器就不知道交通模式，可能會引導卡車穿過住宅區的小巷 (糟糕的查詢計劃)。排序鍵是高速公路出口標誌 — 放置良好的標誌讓你能在高速下進入正確出口；遺失或隱藏的標誌 (排序鍵遺漏或套用了函式) 迫使每輛車都必須停下來搜尋。分散鍵是車輛的住家地址 — 當兩輛相關車輛共享一個地址 (相同分散鍵) 時，它們會到達同一個出口；否則，它們會反覆穿過高速公路 (DS_BCAST_INNER，跨網路重組)。並行調整是尖峰時段的快捷車道，當主幹道擁堵時自動開啟，按快捷車道運作小時計費。
Redshift 作業的常見考試陷阱
DEA-C01 考試設定了一組穩定的陷阱。請記住這五個。
陷阱 1 — 單個巨大檔案的 COPY
場景詢問：「10 TB 單個 CSV 檔案的 COPY 很慢」。錯誤答案：調整叢集規模。正確答案：將來源拆分成許多較小的檔案 (根據切片計數，拆分為 16、32 或更多)。
陷阱 2 — 在複合排序鍵上執行 VACUUM REINDEX
考生在每個資料表上都執行 VACUUM REINDEX。錯誤 — REINDEX 僅對 INTERLEAVED 排序鍵是必要的。在 COMPOUND 排序鍵上執行它是徒勞的。
陷阱 3 — 限制強制執行假設
考生假設 PRIMARY KEY 在 COPY 時會拒絕重複資料。錯誤 — Redshift 限制僅為中繼資料。重複資料刪除是 ETL 的責任。
陷阱 4 — 將手動 WLM 作為預設值
考生預設使用具有僵硬佇列配置的手動 WLM。對於大多數工作負載而言是錯誤的 — 自動 WLM 具備適應性，是推薦的基準。
陷阱 5 — 為了速度而使用 PARALLEL OFF 執行 UNLOAD
考生誤以為 PARALLEL OFF 更快，因為「沒有平行處理開銷」。錯誤 — PARALLEL OFF 使用單個切片，對於大型匯出而言慢得多。PARALLEL ON 是處理量的正確選擇。
COPY 平行度等於 min(檔案數量, 切片數量)。將來源資料拆分為等於叢集切片計數倍數的檔案數量，理想情況下壓縮後每個檔案為 1 MB 到 1 GB。帶有 PARALLEL ON 的 UNLOAD 是平行預設值；PARALLEL OFF 是單切片且慢得多。VACUUM SORT 用於重新排序，DELETE 用於回收，FULL 用於兩者，REINDEX 僅用於 INTERLEAVED 排序鍵。限制僅為中繼資料 — 在插入時不強制執行。 這是針對 DEA-C01 上每個 Redshift 營運問題需要記住的一段文字。如果場景詞是「COPY 緩慢」，答案是檔案拆分。如果是「UNLOAD 緩慢」，選擇 PARALLEL ON。如果是「查詢隨時間變慢」，選擇 VACUUM 與 ANALYZE。如果是「載入了重複資料」，則限制未強制執行。如果是「突發讀取負載」，選擇並行調整。營運命令是基石；排序鍵與分散鍵調校是第二層。
關鍵數據與必須記住的 Redshift 營運事實
COPY
- 檔案數量應為叢集切片計數的倍數
- 檔案大小：壓縮後每個 1 MB 到 1 GB
- 格式：CSV、JSON、Avro、ORC、Parquet、TEXT
- COMPUPDATE 與 STATUPDATE 對空資料表預設為 ON，後續載入設為 OFF
- 連接到叢集的 IAM_ROLE 用於 S3 讀取
UNLOAD
- PARALLEL ON 預設 — 對於大型匯出最快
- PARALLEL OFF — 單個排序後的輸出檔案，慢
- MAXFILESIZE 限制每個檔案的大小
- ALLOWOVERWRITE 用於非空目標前綴
- ENCRYPTED 用於 SSE-KMS 輸出
VACUUM
- SORT ONLY：僅重新排序
- DELETE ONLY：僅回收空間
- FULL：重新排序加上回收空間 (預設)
- REINDEX：僅限 INTERLEAVED 排序鍵
- BOOST 配置更多叢集資源
- RA3 在背景執行自動 VACUUM
ANALYZE
- 更新規劃器統計資訊
- 在發生重大變更 (超過 10% 的資料列) 後執行
- PREDICATE COLUMNS 變體僅分析 WHERE/JOIN/GROUP BY 欄位
- RA3 自動執行 ANALYZE
WLM
- 推薦將自動 WLM 作為預設值
- 手動 WLM 用於保證資源的佇列
- 查詢優先級從 HIGHEST 到 LOWEST
- 短查詢加速 (SQA) 快速處理預測為短時間的查詢
- 並行調整 (Concurrency Scaling) 吸收突發讀取負載，每 24 小時贈送一小時免費時數
限制 (Constraints)
- PRIMARY KEY、UNIQUE、FOREIGN KEY 僅為中繼資料
- 在插入時不強制執行
- 查詢規劃器用於計劃優化
- 資料完整性是 ETL 的責任
DEA-C01 考試重點 — Redshift 查詢調校、COPY 與 UNLOAD。 此主題在 DEA-C01 考試中佔有相當權重。掌握每個 AWS 服務所暴露的權衡、決策邊界以及成本/效能觸發點 — 考試將測試那些依賴於知道哪個服務是錯誤答案，而不僅僅是哪個服務是正確答案的場景。
定義 — Redshift 查詢調校、COPY 與 UNLOAD。 此 DEA-C01 主題涵蓋了特定領域的 AWS 服務或模式。在依賴第三方摘要之前，請先確認來自官方 AWS 文件的典型定義 — 服務名稱和功能範圍隨時間有所變動。
常見問題 (FAQ) — Redshift 查詢調校、COPY 與 UNLOAD
Q1 — S3 的 COPY 效能中單一最大影響因素是什麼？
是相對於叢集切片計數的輸入檔案數量。每個檔案剛好由一個切片處理；如果檔案數量少於切片數量，則切片會閒置。建議：將來源資料拆分為等於切片計數倍數的檔案數量，且壓縮後每個檔案大小在 1 MB 到 1 GB 之間。對於一個 8 節點的 ra3.4xlarge 叢集 (16 個切片)，拆分為 16、32、48 個檔案。對於初始載入後的後續載入，將其與 COMPUPDATE OFF 和 STATUPDATE OFF 結合使用，並在受控時間單獨執行 ANALYZE。DEA-C01 考試直接測試這一點，題目如「COPY 很慢，什麼對效能影響最大」 — 答案是檔案拆分，而不是叢集擴展。
Q2 — 我該如何在 COMPOUND 與 INTERLEAVED 排序鍵之間做選擇？
幾乎所有的生產資料表都應使用 COMPOUND。COMPOUND 按列出的欄位順序進行排序 — 當查詢在第一個或前兩個欄位上進行過濾或聯結時非常完美 (這是按日期分割的事實資料表的典型模式)。僅當查詢對多個具有相似選擇性和相似頻率的排序欄位進行過濾，且資料集大到足以證明載入開銷是值得的時候，才使用 INTERLEAVED。INTERLEAVED 需要定期的 VACUUM REINDEX，而 COMPOUND 則不需要，且 INTERLEAVED 的載入速度較慢，因為 Redshift 必須計算交錯順序。在實踐中，只有不到 10% 的生產資料表能從 INTERLEAVED 中受益。DEA-C01 考試透過排序鍵選擇場景來測試這一點 — 如果工作負載描述為「主要按日期過濾」，則在日期上使用 COMPOUND 是答案。
Q3 — 我應該何時以及如何在 RA3 節點上執行 VACUUM？
RA3 在背景執行自動 VACUUM 與 ANALYZE，並排定在低負載期間，這處理了典型工作負載的大多數維護工作。在發生非常大的資料變更 (大量批次 DELETE、大型 UPDATE、向已排序資料表進行大型 INSERT) 後，或者當系統檢視顯示明顯的未排序區域或已刪除資料列空間時，執行手動 VACUUM 仍然是適當的。對於 RA3 上的典型工作負載，每週或每月在維護期間排定一次 VACUUM FULL 是一個合理的雙重保險做法。對於具有 INTERLEAVED 排序鍵的資料表，在發生重大變更後排定 VACUUM REINDEX — 自動 VACUUM 不處理交錯 REINDEX。在非 RA3 (DC2 及更早版本) 上，自動 VACUUM 不會執行，需要明確排程。
Q4 — 如何診斷 Redshift 中的慢查詢？
從在慢查詢前執行 EXPLAIN 開始。尋找：在你預期 Index Scan 的地方出現 Seq Scan (排序鍵遺漏)、資料移動列上的 DS_BCAST_INNER 或 DS_DIST_BOTH (分散鍵不匹配導致網路重組)、大型資料表上的 nested loop join (規劃器選錯了聯結演算法，通常是因為統計資訊過時)，以及在本應廉價的運算子上出現高 cost 值。交叉參考 STL_QUERY 以獲取實際執行時間，以及 SVL_QUERY_REPORT 以獲取每個步驟的持續時間。如果統計資訊看起來過時，請執行 ANALYZE PREDICATE COLUMNS。如果在 SVV_TABLE_INFO 中看到明顯的分散偏斜，請變更分散鍵或改用 DISTSTYLE EVEN。如果工作負載受限於並行度，請啟用並行調整 (Concurrency Scaling)。DEA-C01 考試透過題目幹中的 EXPLAIN 輸出片段來測試這些診斷步驟。
Q5 — 自動 WLM 與手動 WLM 有什麼區別，我應該使用哪一個？
自動 WLM 根據觀察到的工作負載模式動態地在佇列之間配置記憶體與並行度；手動 WLM 使用靜態記憶體百分比和每個佇列的並行限制。自動 WLM 是幾乎所有叢集的推薦基準，因為它的適應速度比人工重新調校手動佇列更快，尤其是對於變動的工作負載。僅當特定佇列需要保證資源時才使用手動 WLM — 例如，關鍵的高階主管儀表板佇列不能被分析師的臨時查詢耗盡資源 — 或者當 ML 驅動的成本配置需要確定的每個佇列計費時。在任一模型中，啟用短查詢加速 (SQA) 以快速處理預測為短時間的查詢，並啟用並行調整以吸收讀取突發負載。DEA-C01 考試會以「團隊擁有不可預測的工作負載組合」場景測試這一點，自動 WLM 是正確答案。
Q6 — 為什麼我的資料表有 PRIMARY KEY，但 COPY 卻載入了重複的資料列？
因為 Redshift 不強制執行 PRIMARY KEY、UNIQUE 或 FOREIGN KEY 限制 — 它們僅為中繼資料。查詢規劃器使用限制中繼資料來跳過某些計劃中的重複資料刪除 (規劃器優化)，但插入與 COPY 不會檢查限制。資料完整性是 ETL 的責任。常見模式：在上游 ETL 中使用 ROW_NUMBER() OVER (PARTITION BY id ORDER BY load_time DESC) = 1 進行去重，僅保留最新的資料列，或者使用「預備資料表加上合併 (merge)」模式 (COPY 到預備表，從目標表刪除匹配的列，從預備表插入)。DEA-C01 考試常以此設局，如「儀表板計數中出現重複資料列」或「聲明了主索引鍵但載入了重複資料」場景。
Q7 — 我應該何時使用並行調整 (Concurrency Scaling)？
在讀取查詢量在一天或一週內變動顯著的工作負載上啟用並行調整 — 典型模式包括在工作時間急劇增加的儀表板、每晚執行的批次報告，或分析師驅動的不可預測的探索。並行調整會在主叢集佇列填滿時自動提供額外的叢集容量，在擴展叢集處於活動狀態時按秒計費，且每 24 小時主叢集運作時間提供一小時免費擴展。唯讀查詢符合資格。在 WLM 佇列層級配置。對於關於「使用者抱怨在尖峰期間等待」或「主叢集 CPU 正常但查詢排隊」的 DEA-C01 考試場景，並行調整是正確答案；永久調整叢集規模則是一個干擾項，因為它會讓你為 24/7 的尖峰容量付費，而實際尖峰僅持續幾小時。
延伸閱讀 — Redshift 作業的官方 AWS 文件
權威的 AWS 來源包括《Redshift 資料庫開發人員指南》(COPY、UNLOAD、VACUUM、ANALYZE 參考)、《Redshift 叢集管理指南》(WLM、並行調整、RA3 自動維護) 以及 Redshift 最佳實踐文件 (排序鍵、分散鍵、檔案大小調整)。AWS 大數據部落格有多篇關於 COPY 平行處理、EXPLAIN 計劃讀取與偏斜診斷的深入探討文章。AWS Well-Architected Data Analytics Lens 涵蓋了分析階段的 Redshift。AWS Samples GitHub 儲存庫包含端對端管道，展示了使用資訊清單檔案從 S3 進行 COPY 以及 UNLOAD 為 Parquet 的模式。最後，Skill Builder DEA-C01 考試準備標準課程具有專門的 Redshift 作業模組，以場景形式引導學員了解典型的考試陷阱。