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 中查詢效能的強大工具。其透過儲存預先計算的結果集來做到這一點。類似的查詢不必每次都重新執行相同的邏輯，因為它們可以從現有的結果集擷取記錄。開發人員和分析師會在分析工作負載之後建立具體化視觀表，以判斷哪些查詢可以受益，以及每個具體化視觀表的維護成本是否值得。隨著工作負載的增長或變化，這些具體化視觀表必須經過審查，以確保它們繼續提供實際的效能優勢。
Redshift 中的自動具體化視觀表 (AutoMV) 功能會根據工作負載監控和機器學習演算法自動建立和管理具體化視觀表，以增強查詢效能。以下包括 AutoMV 的重要功能：
+ *持續監控* - Redshift 使用機器學習技術持續監控工作負載，以透過建立具體化視觀表來找出改善效能的機會。
+ *自動建立和刪除* - 當系統偵測到具體化視觀表會有幫助時，便會自動建立和維護它。相反地，如果先前建立的 AutoMV 不再提供效能優勢，系統便會自動將其捨棄。
+ *無使用者活動需求* - AutoMV 功能只會在叢集上處於低使用者活動或低工作負載的期間運作。這可確保 AutoMV 操作不會干擾或影響客戶工作負載。
+ *CPU 用量激增* - 在無工作負載活動的期間，若 AutoMV 建立或重新整理具體化視觀表，則可能會導致 CPU 用量激增。這是正常行為，因為系統會利用可用的資源來建立和重新整理具體化視觀表。
+ *使用者工作負載優先順序* - 如果您在 AutoMV 操作進行時啟動工作負載，AutoMV 任務會停止，以釋出資源供使用者工作負載使用。這可確保您的工作負載優先於 AutoMV 操作。
雖然 AutoMV 功能可能會在無使用者活動期間導致 CPU 用量激增，但其運作公開透明，且不會影響您的工作負載。系統會管理具體化視觀表以改善查詢效能，並同時排定優先處理使用者工作負載，而非 AutoMV 操作。
AutoMV 行為和功能與使用者建立的具體化視觀表相同。其使用相同的準則和限制以自動且累加的方式進行重新整理。就像使用者建立的具體化視觀表一樣，[自動查詢重寫以使用具體化視檢視](materialized-view-auto-rewrite.md) 會識別可受益於系統建立之 AutoMV 的查詢。它會自動重寫這些查詢以使用 AutoMV，從而改善查詢效能。開發人員不需要修改查詢即可利用 AutoMV。
**注意**
自動具體化視觀表會間歇性重新整理。重寫為使用 AutoMV 的查詢永遠會傳回最新的結果。當 Redshift 偵測到資料不是最新的時候，就不會將查詢重寫為從自動具體化視觀表讀取。相反地，查詢會從基底資料表中選取最新資料。
任何具有重複使用之查詢的工作負載都可以受益於 AutoMV。常用案例包括：
+ *儀表板* - 儀表板廣泛用於提供關鍵業務指標 (KPI)、事件、趨勢和其他指標的快速檢視。它們通常具有包含圖表和資料表的通用版面配置，但會顯示不同的檢視來用於篩選或維度選取操作 (例如向下鑽研)。儀表板通常有一組共同的查詢，以不同的參數重複使用。儀表板查詢可以從自動具體化視觀表中獲益匪淺。
+ *報告* - 報告查詢可以安排在不同的頻率下進行，根據業務需求和報告的類型。此外，它們可以是自動或隨需形式。報告查詢的一個共同特徵是可以長時間執行且屬於資源密集型。使用 AutoMV 時，這些查詢不需要在每次執行時重新計算，這會減少 Redshift 中每個查詢的執行期和資源使用率。
若要關閉自動具體化視觀表，請將 `auto_mv` 參數群組更新為 `false`。如需詳細資訊，請參閱《Amazon Redshift 叢集管理指南》中的 [Amazon Redshift 參數群組](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html)。
## 自動具體化視觀表的 SQL 範圍和考量
+ 自動具體化視觀表可以由查詢或子查詢啟動和建立，前提是它包含 `GROUP BY` 子句或下列其中一個彙總函數：SUM、COUNT、MIN、MAX 或 AVG。但不能包含以下任何項目：
+ 左側、右側或完整外部聯結
+ SUM、COUNT、MIN、MAX 與 AVG 以外的彙總函數。(這些特定函式可與自動查詢重寫搭配使用。)
+ 任何包含 DISTINCT 的彙總函數
+ 任何範圍函數
+ SELECT DISTINCT 或 HAVING 子句
+ 其他具體化視觀表
不保證符合準則的查詢會啟動自動具體化視觀表的建立。系統會根據其對工作負載的預期效益和要維護的資源成本 (包括系統要重新整理的成本)，決定要從哪些候選項目建立檢視。每個產生的具體化視觀表都可透過自動查詢重寫來使用。
+ 即使 AutoMV 可能是由子查詢或集合運算子的個別支段啟動，產生的具體化視觀表也不會包含子查詢或集合運算子。
+ 若要判斷 AutoMV 是否用於查詢，請檢視 EXPLAIN 計劃並在輸出中尋找 `%_auto_mv_%`。如需詳細資訊，請參閱 [EXPLAIN](https://docs.aws.amazon.com/redshift/latest/dg/r_EXPLAIN.html)。
+ 外部資料表 (例如資料共用和聯合資料表) 不支援自動具體化視觀表。
## 自動具體化視觀表限制
下列是使用自動具體化視觀表的限制：
+ *AutoMV 的最大數目* - 叢集中每個資料庫的自動具體化視觀表限制為 200 個。
+ *儲存空間和容量* - AutoMV 的一個重要特點是，它是使用備用背景週期來執行，以協助實現使用者工作負載不受影響的目的。如果叢集忙碌或儲存空間不足，AutoMV 會停止其活動。具體而言，在叢集總容量的 80% 時，不會建立新的自動具體化視觀表。在總容量的 90% 時，它們可能會被捨棄，以在不降低校能的情況下繼續使用者工作負載。如需決定叢集容量的相關資訊，請參閱 [STV\$1NODE\$1STORAGE\$1CAPACITY](r_STV_NODE_STORAGE_CAPACITY.md)。
## 自動具體化視觀表的計費
Amazon Redshift 的自動最佳化功能可建立和重新整理自動具體化視觀表。此程序的運算資源無須付費。自動具體化視觀表的儲存費用是以一般儲存費率計費。如需詳細資訊，請參閱 [Amazon Redshift 定價](https://aws.amazon.com/redshift/pricing/)。
## 其他資源
下列部落格文章提供有關自動具體化視觀表的進一步說明 其中詳細介紹了其建立、維護和捨棄方式。還說明了推動這些決策的基礎演算法：[使用自動具體化視觀表最佳化 Amazon Redshift 查詢效能](https://aws.amazon.com/blogs//big-data/optimize-your-amazon-redshift-query-performance-with-automated-materialized-views/)。
此影片從具體化視觀表的說明開始，並示範其如何改善效能及節省資源。然後，透過程序流程動畫和現場示範，提供自動具體化視觀表的深入說明。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/-85GSBQOBTA)