影響查詢效能的因素

節點、處理器或配量的數量 – 運算節點會分割為配量。更多節點表示更多處理器和更多配量，透過在配量間並行執行部分的查詢，可讓您的查詢處理得更快速。不過，更多節點也表示更大的開支，因此必須尋找適合您的系統的成本與效能的平衡點。如需 Amazon Redshift 叢集架構的相關資訊，請參閱資料倉儲系統架構。

節點類型 - Amazon Redshift 叢集可以使用數種節點類型之一。每個節點類型可提供不同的大小和限制，以幫助您適當地調整叢集的規模。節點大小決定叢集中每個節點的儲存容量、記憶體CPU、 和價格。如需節點類型的相關資訊，請參閱《Amazon Redshift 管理指南》中的 Amazon Redshift 叢集概觀。

資料配送 – Amazon Redshift 會根據資料表的配送樣式，將資料表資料儲存在運算節點。當您執行查詢時，查詢最佳化器會視需要將資料重新配送至運算節點，以執行任何聯結與彙整。選擇資料表的適當配送樣式，有助於降低重新配送步驟所帶來的影響，方法是在執行聯結之前，將資料放置在需要的位置。如需詳細資訊，請參閱查詢最佳化的資料分佈。

資料排序排列 – Amazon Redshift 會根據資料表的排序索引鍵，以排序的順序將資料表資料儲存在磁碟上。查詢最佳化器和查詢處理器使用資料所在位置的資訊以減少必須掃描的區塊數量，藉以改善查詢速度。如需詳細資訊，請參閱排序金鑰。

資料集大小 – 由於需要掃描和重新配送更多資料列，因此叢集中較多的資料量可能拖慢查詢的查詢效能。您可以透過定期清空和封存資料，以及使用述詞來限制查詢資料集，藉以減緩此影響。

並行操作 – 一次執行多個操作可能影響查詢效能。每個操作會使用可用查詢佇列中的一或多個位置，並使用與那些位置關聯的記憶體。如果其他操作正在執行，則可能沒有足夠的查詢佇列位置可供使用。在此情況下，查詢必須等候位置開放之後才可以開始處理。如需建立和設定查詢佇列的相關資訊，請參閱工作負載管理。

查詢結構 – 寫入查詢的方式會影響其效能。請對程序寫入盡可能多的查詢，並傳回符合您需求的最少資料。如需詳細資訊，請參閱設計查詢的 Amazon Redshift 最佳實務。

程式碼編譯 – Amazon Redshift 會為每個查詢執行計畫產生和編譯程式碼。

編譯的程式碼執行得更快速，因為它省去了使用解譯器的間接成本。第一次產生和編譯程式碼時，通常會有些間接成本。因此，第一次執行查詢的效能可能會有偏差。執行一次性查詢時的間接成本可能特別明顯。請進行第二次執行查詢，以便判斷其一般效能。Amazon Redshift 使用無伺服器編譯服務，將查詢編譯擴展到 Amazon Redshift 叢集的運算資源之外。編譯的程式碼區段會在叢集本機上快取，而且會在幾乎無限制的快取中快取。此快取會在叢集重新啟動後持續存在。相同查詢的後續執行可以加快執行速度，因為它可以略過編譯階段。

快取在 Amazon Redshift 版本之間不相容，因此會清除編譯快取，並在版本升級後執行查詢時重新編譯程式碼。如果您的查詢具有嚴格的 SLAs，我們建議您預先執行查詢區段，以從叢集資料表掃描資料。這可讓 Amazon Redshift 快取基礎資料表資料，減少版本升級後的查詢規劃時間。透過使用可擴展的編譯服務，Amazon Redshift 可以並行編譯程式碼以提供一致的快速效能。工作負載加速的程度取決於查詢的複雜性和並行性。