本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Amazon Redshift 的查詢效能因素
有一些因素會影響查詢效能。資料、叢集和資料庫操作的下列層面，都對查詢的處理速度扮演著重要角色：
資料表屬性
Amazon Redshift 資料表是將資料存放在 Amazon Redshift 中的基本單位，而且每個資料表都有一組屬性來決定其行為和可存取性。這些屬性包括排序、分佈樣式、壓縮編碼等。了解這些屬性對於最佳化 Amazon Redshift 資料表的效能、安全性和成本效益至關重要。
排序索引鍵
Amazon Redshift 會根據資料表的排序索引鍵，以排序順序將資料存放在磁碟上。查詢最佳化工具和查詢處理器會使用資料位於運算節點中位置的相關資訊，以減少必須掃描的區塊數量。這可減少要處理的資料量，大幅提高查詢速度。我們建議您使用排序索引鍵，以方便 WHERE子句中的篩選條件。如需詳細資訊，請參閱《Amazon Redshift 文件》中的使用排序索引鍵。
資料壓縮
資料壓縮可減少儲存需求，進而減少磁碟輸入/輸出並改善查詢效能。當您執行查詢時，壓縮的資料會讀取到記憶體，然後在查詢執行時取消壓縮。透過將較少的資料載入記憶體，Amazon Redshift 可以配置更多記憶體來分析資料。由於單欄式儲存會循序存放類似的資料，Amazon Redshift 可以套用專門與單欄式資料類型綁定的適應性壓縮編碼。在資料表資料欄上啟用資料壓縮的最佳方法是使用 Amazon Redshift 中的 AUTO選項，在載入具有資料的資料表時套用最佳壓縮編碼。若要進一步了解如何使用自動資料壓縮，請參閱《Amazon Redshift 文件》中的使用自動壓縮載入資料表。
資料分佈
Amazon Redshift 會根據資料表的分佈樣式將資料存放在運算節點上。當您執行查詢時，查詢最佳化器會視需要將資料重新配送至運算節點，以執行任何聯結與彙整。選擇資料表的適當配送樣式，有助於降低重新配送步驟所帶來的影響，方法是在執行聯結之前，將資料放置在需要的位置。我們建議您使用分佈索引鍵來促進最常見的聯結。如需詳細資訊，請參閱《Amazon Redshift 文件》中的使用資料分佈樣式。
資料表維護
雖然 Amazon Redshift 為大多數工作負載提供業界領先的立即可用效能，但保持 Amazon Redshift 叢集正常運作需要維護。更新和刪除資料會建立必須清空的無效資料列，而且如果附加順序與排序索引鍵不一致，甚至必須排序僅附加資料表。
Vacuum
Amazon Redshift 中的清空程序對於 Amazon Redshift 叢集的運作狀態和維護至關重要。它也會影響查詢的效能。由於 刪除和更新會同時標記舊資料，但實際上並未移除它，因此您必須使用清空來回收由先前 UPDATE和 DELETE操作標記為刪除的資料表列佔用的磁碟空間。Amazon Redshift 可以自動排序和對背景中的資料表執行VACUUM DELETE操作。
如要在載入或一系列的累加式更新之後清理資料表，您也可以對整個資料庫或個別資料表執行 VACUUM 命令。如果資料表具有排序索引鍵，且資料表負載未最佳化，無法於插入時排序，則您必須使用清空來排序資料 （這對效能至關重要）。如需詳細資訊，請參閱《Amazon Redshift 文件》中的清空資料表。
分析
ANALYZE 操作會更新 Amazon Redshift 資料庫中資料表的統計中繼資料。讓統計資料保持在最新狀態，可讓查詢規劃工具選擇最佳計劃，進而改善查詢效能。Amazon Redshift 會持續監控資料庫，並自動在背景中執行分析操作。為了將對系統效能的影響降至最低，ANALYZE操作會在工作負載較輕的期間自動執行。如果您選擇明確執行 ANALYZE，請執行下列動作：
-
在執行查詢之前執行
ANALYZE命令。 -
在每個一般載入或更新週期結束時，定期在資料庫上執行
ANALYZE命令。 -
在您建立的新資料表和經歷重大變更的現有資料表或資料欄上執行
ANALYZE命令。 -
考慮在不同資料表和資料欄類型的排程上執行
ANALYZE操作，取決於它們在查詢中的使用，以及變更的傾向。 -
若要節省時間和叢集資源，請在執行
ANALYZE命令時使用PREDICATE COLUMNS子句。
叢集組態
叢集是節點的集合，可執行實際的資料儲存和處理。如果您想要達成下列目標，以正確的方式設定 Amazon Redshift 叢集至關重要：
-
高可擴展性和並行
-
有效使用 Amazon Redshift
-
更好的效能
-
降低成本
節點類型
Amazon Redshift 叢集可以使用多種節點類型 (RA3、DC2 和 DS2) 的其中之一。每個節點類型可提供不同的大小和限制，以幫助您適當地調整叢集的規模。節點大小會決定叢集中每個節點的儲存容量、記憶體、CPU 和價格。成本和效能最佳化從選擇正確的節點類型和大小開始。如需節點類型的詳細資訊，請參閱《Amazon Redshift 文件》中的 Amazon Redshift 叢集概觀。
節點大小、節點數量和配量
運算節點可分割為分割。更多節點表示更多的處理器和配量，這可讓您的查詢透過跨配量同時執行部分查詢，以更快地處理。不過，更多節點也表示費用更高。這表示您必須找到適合您系統的成本和效能平衡。如需 Amazon Redshift 叢集架構的詳細資訊，請參閱《Amazon Redshift 文件》中的資料倉儲系統架構。
工作負載管理
Amazon Redshift 工作負載管理 (WLM) 可讓使用者以優先順序靈活管理工作負載佇列，如此短而快速執行的查詢就不會卡在長時間執行查詢後的佇列中。自動 WLM 使用機器學習 (ML) 演算法來描述查詢，並將其放置在具有適當資源的適當佇列中，同時管理查詢並行和記憶體配置。如需 WLM 的詳細資訊，請參閱《Amazon Redshift 文件》中的實作工作負載管理。
短期查詢加速
短查詢加速 (SQA) 會優先處理短執行查詢，然後再處理長執行查詢。SQA 會在專用空間中執行查詢，因此 SQA 查詢不會強制在較長查詢後的佇列中等待。SQA 只優先處理短期執行且位於使用者定義佇列中的查詢。如果您使用 SQA，短期執行的查詢會更快開始執行，而且您可以更快看到結果。如果您啟用 SQA，您可以減少或消除專用於短期執行查詢的 WLM 佇列。此外，長時間執行的查詢不需要爭用 WLM 佇列中的槽。這表示您可以將 WLM 佇列設定為使用較少的查詢槽。如果您使用較低的並行，查詢輸送量會提高，且大多數工作負載的整體系統效能也會獲得改善。如需 SQA 的詳細資訊，請參閱《Amazon Redshift 文件》中的使用簡短查詢加速。
SQL 查詢
資料庫查詢是從資料庫取得資料的請求。請求應該使用 SQL 出現在 Amazon Redshift 叢集中。Amazon Redshift 支援透過 Java Database Connectivity (JDBC) 和 Open Database Connectivity (ODBC) 連線的 SQL 用戶端工具。您可以使用支援 JDBC 或 ODBC 驅動程式的大多數 SQL 用戶端工具。
查詢結構
您的查詢寫入方式會大幅影響其效能。我們建議您撰寫查詢，以處理和在必要時傳回最少的資料，以滿足您的需求。如需如何建構查詢的詳細資訊，請參閱本指南中設計 Amazon Redshift 查詢的最佳實務一節。
程式碼編譯
Amazon Redshift 會為每個查詢執行計劃產生和編譯程式碼。編譯的程式碼執行得更快速，因為它省去了使用解譯器的間接成本。您通常會在第一次產生和編譯程式碼時支付一些額外成本。因此，第一次執行查詢的效能可能會有偏差。當您執行一次性查詢時，額外負荷成本可能特別明顯。我們建議您再次執行查詢，以判斷其典型效能。
Amazon Redshift 使用無伺服器編譯服務，將查詢編譯擴展到 Amazon Redshift 叢集的運算資源之外。編譯的程式碼區段會在叢集本機上快取，而且會在幾乎無限制的快取中快取。此快取會在叢集重新啟動後持續存在。相同查詢的後續調用執行速度更快，因為它們可以略過編譯階段。快取在 Amazon Redshift 版本之間不相容，因此當查詢在版本升級後執行時，程式碼會重新編譯。透過使用可擴展的編譯服務，Amazon Redshift 可以並行編譯程式碼以提供一致的快速效能。工作負載加速的程度取決於查詢的複雜性和並行性。
