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

Amazon Redshift 的查詢效能因素

有一些因素會影響查詢效能。資料、叢集和資料庫操作的下列層面都有助於查詢的處理速度：

資料表屬性

Amazon Redshift 資料表是將資料存放在 Amazon Redshift 中的基本單位，而且每個資料表都有一組屬性來決定其行為和可存取性。這些屬性包括排序、分佈樣式、壓縮編碼等。了解這些屬性對於最佳化 Amazon Redshift 資料表的效能、安全性和成本效益至關重要。

排序索引鍵

Amazon Redshift 會根據資料表的排序索引鍵，以排序順序將資料存放在磁碟上。查詢最佳化工具與查詢處理器會使用資料位於運算節點中位置的相關資訊，以減少必須掃描的區塊數量。這可透過減少要處理的資料量，大幅改善查詢速度。我們建議您使用排序索引鍵來協助 WHERE子句中的篩選條件。如需詳細資訊，請參閱《Amazon Redshift 文件》中的使用排序索引鍵。

資料壓縮

資料壓縮可減少儲存需求，進而減少磁碟 I/O 並改善查詢效能。當您執行查詢時，壓縮的資料會讀取至記憶體，然後在查詢執行時解壓縮。透過將較少的資料載入記憶體，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，請執行下列動作：

叢集組態

叢集是執行實際儲存和處理資料的節點集合。如果您想要達成下列目標，以正確的方式設定 Amazon Redshift 叢集至關重要：

Node type

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 會平行編譯程式碼，以提供一致的快速效能。