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/)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon Redshift 效能
本主題說明驅動效能的 Amazon Redshift 元件。了解這些元件可協助您使用 Amazon Redshift 調校效能，並解決效能不佳的問題。
Amazon Redshift 運用這些效能功能，實現超快速的查詢執行。
**Topics**
+ [大規模平行處理](#massively-parallel-processing)
+ [單欄式資料儲存體](#columnar-data-storage)
+ [資料壓縮](#data-compression)
+ [查詢最佳化工具](#query-optimizer)
+ [結果快取](#result-caching)
+ [經過編譯的程式碼](#compiled-code)
## 大規模平行處理
大規模平行處理 (MPP) 作業讓處理大量資料的最複雜查詢，也能快速地執行。多重運算節點進行所有查詢處理作業，最後再將結果彙總 (每個節點的核心會針對整個資料的一部分，執行相同的編譯後查詢片段)。
Amazon Redshift 會將資料表的列分發給運算節點，以平行處理資料。透過為每個資料表選擇適合的分佈索引鍵，您可以將資料的分發最佳化，進而平衡工作負載，並且將資料在節點之間的移動次數減到最少。如需詳細資訊，請參閱[選擇最佳的分佈方式](c_best-practices-best-dist-key.md)。
從一般檔案載入資料，可透過將工作負載分散到多個節點，一邊同時從多個檔案讀取，來發揮平行處理的效益。如需如何將資料載入資料表的相關資訊，請參閱[載入資料的 Amazon Redshift 最佳實務](c_loading-data-best-practices.md)。
## 單欄式資料儲存體
資料庫資料表的單欄式儲存方式，大幅地降低了整體磁碟輸入/輸出需求，成為實現最佳化分析查詢效能的重要因素。如需詳細資訊，請參閱[單欄式儲存](c_columnar_storage_disk_mem_mgmnt.md)。
以適當地方式將欄排序時，查詢處理器就能夠快速地篩選掉龐大的資料區塊子集。如需詳細資訊，請參閱[選擇最佳的排序索引鍵](c_best-practices-sort-key.md)。
## 資料壓縮
資料壓縮可降低對儲存空間的需求，進而減少磁碟輸入/輸出，提升查詢作業的效能。執行查詢作業時，會將壓縮的資料讀入記憶體，然後在進行查詢時將資料解壓縮。載入記憶體的資料量減少，即可讓 Amazon Redshift 配置更多的記憶體來分析資料。由於單欄式儲存會依順序儲存類似的資料，Amazon Redshift 就能夠採用與單欄式資料類型特別相關的適應性壓縮編碼機制。對資料表欄進行資料壓縮的最佳方式，就是在載入資料表和資料時，讓 Amazon Redshift 套用最佳化的壓縮編碼機制。如要進一步了解自動資料壓縮，請參閱[利用自動壓縮載入資料表](c_Loading_tables_auto_compress.md)。
## 查詢最佳化工具
Amazon Redshift 查詢執行引擎採用支援 MPP 的查詢最佳化工具，也運用了欄式導向的資料儲存體。Amazon Redshift 查詢最佳化工具建置了重大的增強與擴充功能，可用來處理複雜的分析查詢作業，這類查詢經常包含多重資料表的合併、子查詢和彙總操作。若要進一步了解如何將查詢作業最佳化，請參閱[調校查詢效能](c-optimizing-query-performance.md)。
## 結果快取
為了縮短查詢執行期並改善系統效能，Amazon Redshift 會將特定查詢類型的結果快取在領導者節點的記憶體中。當使用者提交查詢時，Amazon Redshift 會針對結果快取，檢查是否建立了查詢結果的有效快取副本。如果在結果快取中找到符合者，Amazon Redshift 會使用快取的結果，不會執行查詢。使用者並不會察覺到結果快取作業的進行。
結果快取預設為開啟。若要關閉目前工作階段的結果快取作業，請將 [enable\_result\_cache\_for\_session](r_enable_result_cache_for_session.md) 參數設定為 `off`。
當下列所有情況都符合時，Amazon Redshift 會使用新查詢的快取結果：
+ 提交查詢的使用者，對查詢中所使用的物件具有存取許可。
+ 查詢中的資料表或檢視尚未經過修改。
+ 查詢並未使用每次執行時都必須求值的函式，例如 GETDATE。
+ 查詢並未參考 Amazon Redshift Spectrum 外部資料表。
+ 可能影響查詢結果的組態參數不變。
+ 查詢在語法上符合快取的查詢。
為了最大限度地提高快取效率並有效利用資源，Amazon Redshift 不會快取某些大型查詢結果集。Amazon Redshift 會根據許多因素判斷是否要快取查詢結果。這些因素包括快取中的項目數量，以及 Amazon Redshift 叢集的執行個體類型。
若要判斷查詢作業是否使用了結果快取，請查詢 [SVL\_QLOG](r_SVL_QLOG.md) 系統畫面。如果查詢使用了結果快取，source\_query 欄會傳回來源查詢的查詢 ID。如果未使用結果快取，source\_query 欄的值為 NULL。
下列範例顯示，由 userid 104 和 userid 102 所提交的查詢，使用了 userid 100 所執行查詢的結果快取。
```
select userid, query, elapsed, source_query from svl_qlog
where userid > 1
order by query desc;
userid | query | elapsed | source_query
-------+--------+----------+-------------
104 | 629035 | 27 | 628919
104 | 629034 | 60 | 628900
104 | 629033 | 23 | 628891
102 | 629017 | 1229393 |
102 | 628942 | 28 | 628919
102 | 628941 | 57 | 628900
102 | 628940 | 26 | 628891
100 | 628919 | 84295686 |
100 | 628900 | 87015637 |
100 | 628891 | 58808694 |
```
## 經過編譯的程式碼
程式碼編譯 – Amazon Redshift 會為每個查詢執行計畫產生和編譯最佳化程式碼。編譯的程式碼執行速度更快，因為它消除了使用解譯器的額外負荷。為了將新查詢的延遲降至最低，同時保留編譯程式碼的效能優勢，Amazon Redshift 使用稱為合成的技術。合成會產生預先存在邏輯的輕量型配置，以立即處理新查詢，同時在背景編譯高度最佳化的查詢特定程式碼。這會從查詢執行的關鍵路徑移除編譯，因此新查詢的啟動速度更快，並提供與後續執行一致的效能。
Amazon Redshift 也會使用無伺服器編譯服務，將查詢編譯擴展到 Amazon Redshift 叢集的運算資源之外。編譯的程式碼區段會在本機快取在叢集上，並在叢集重新啟動後持續存在的幾乎無限制的遠端快取中。相同查詢的後續執行可以加快執行速度，因為它可以略過編譯階段。透過使用可擴展的編譯服務，Amazon Redshift 會平行編譯程式碼，以提供一致的快速效能。