本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 在 Aurora PostgreSQL 中最佳化查詢效能最佳化查詢效能至關重要，因為其有助於資料庫更快速、更有效率地執行，同時使用較少的資源，進而提供更好的使用者體驗與降低營運成本。Amazon Aurora PostgreSQL 提供數種功能，可協助最佳化 PostgreSQL 工作負載的查詢效能。 **Topics** + [使用 Aurora Optimized Reads 改善 Aurora PostgreSQL 的查詢效能](AuroraPostgreSQL.optimized.reads.md) + [最佳化 Aurora PostgreSQL 中的相互關聯子查詢](apg-correlated-subquery.md) + [使用調適型聯結改善查詢效能](user-apg-adaptive-join.md) + [使用共用計劃快取](apg-shared-plan-cache.md) # 使用 Aurora Optimized Reads 改善 Aurora PostgreSQL 的查詢效能您可以使用 Aurora Optimized Reads，為 Aurora PostgreSQL 實現更快的查詢處理。使用 Aurora Optimized Reads 的 Aurora PostgreSQL 資料庫執行個體可為具有大型資料集 (超過資料庫執行個體記憶體容量) 的應用程式提供高達 8 倍的查詢延遲改進，以及高達 30% 的成本節省。 **Topics** + [PostgreSQL 中 Aurora Optimized Reads 的概觀](#AuroraPostgreSQL.optimized.reads.overview) + [使用 Aurora Optimized Reads](#AuroraPostgreSQL.optimized.reads.using) + [Aurora Optimized Reads 的使用案例](#AuroraPostgreSQL.optimized.reads.usecases) + [監控使用 Aurora Optimized Reads 的資料庫執行個體](#AuroraPostgreSQL.optimized.reads.monitoring) + [Aurora Optimized Reads 的最佳實務](#AuroraPostgreSQL.optimized.reads.bestpractices) ## PostgreSQL 中 Aurora Optimized Reads 的概觀當您建立使用 Graviton 型 R6gd, R8gd 和 Intel 型 R6id 執行個體搭配非揮發性記憶體快速 (NVMe) 儲存體的資料庫叢集時，預設可以使用 Aurora Optimized Reads。它可從以下 PostgreSQL 版本取得： + 適用於 R8gd 執行個體的 14.12 和更新版本、15.7 和更新版本、16.3 和更新版本、17.4 和更新版本 + 14.9 和更新版本、15.4 和更新版本、16.1 和 R6gd 和 R6id 執行個體的所有更新版本 Aurora Optimized Reads 支援兩種功能：階層式快取和暫存物件。 **啟用 Optimized Reads 的階層式快取** - 使用階層式快取，您可以將資料庫執行個體快取容量擴充至執行個體記憶體的 5 倍。這會自動維護快取以包含最新的交易一致性資料，讓應用程式免於管理外部結果集型快取解決方案之資料貨幣的額外負荷。它為先前從 Aurora 儲存獲取資料的查詢提供了高達 8 倍的延遲。在 Aurora 中，預設參數群組中的 `shared_buffers` 值通常設定為可用記憶體的大約 75%。不過，對於 r8gd、r6gd 和 r6id 執行個體類型，Aurora 會將`shared_buffers`空間減少 4.5%，以託管 Optimized Reads 快取的中繼資料。 **已啟用 Optimized Reads 的暫存物件** - 使用暫存物件，您可將 PostgreSQL 產生的暫時檔案放置在本機 NVMe 儲存體上，實現更快的查詢處理。如此可減少透過網路傳送至彈性區塊儲存 (EBS) 的流量。對於進階查詢進行排序、聯結或合併不適合資料庫執行個體上可用記憶體容量的大量資料，可提供高達 2 倍的延遲和輸送量。在 Aurora I/O 最佳化叢集上，Optimized Reads 會在 NVMe 儲存裝置上同時使用階層式快取和暫存物件。透過啟用 Optimized Reads 的階層式快取功能，Aurora 會為暫存物件分配 2 倍的執行個體記憶體、約 10% 的儲存用於內部作業，而剩餘的儲存裝置則分配為階層式快取。在 Aurora 標準叢集上，Optimized Reads 僅會使用暫存物件。 Aurora I/O 最佳化叢集可讓您使用執行個體層級的動態參數 `aurora_temp_space_size`，調整已啟用 Optimized Reads 之臨時物件的配置空間大小。此調整大小功能可從以下 PostgreSQL 版本取得： + 16.8 版和所有更新版本 + 15.12 版和更新的 15 版本 + 14.17 版和更新的 14 版本使用此參數，您可以調整容量大小，從 2 倍到最多 6 倍的執行個體記憶體，而不需要重新啟動資料庫引擎。當您擴展臨時物件空間時，無論並行工作負載為何，變更都會立即生效。不過，當您減少空間時，只有在臨時物件中有足夠的未使用空間來容納新的大小請求之後，調整才會完成。調整已啟用 Optimized Reads 的臨時物件大小後，分層快取會自動調整以使用任何可用的空間。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.optimized.reads.html) **注意** 在 NVMe 型資料庫執行個體類別上的 IO 最佳化和標準叢集之間進行切換，會立即重新啟動資料庫引擎。在 Aurora PostgreSQL 中，使用 `temp_tablespaces` 參數設定儲存臨時物件的資料表空間。若要檢查臨時物件是否已正確設定，請使用下列命令： ``` postgres=> show temp_tablespaces; temp_tablespaces --------------------- aurora_temp_tablespace (1 row) ``` `aurora_temp_tablespace` 是 Aurora 設定的資料表空間，指向 NVMe 本機儲存體。您無法修改此參數或切換回 Amazon EBS 儲存體。若要檢查是否已開啟最佳化的讀取快取，請使用下列命令： ``` postgres=> show shared_preload_libraries; shared_preload_libraries -------------------------------------------------------- rdsutils,pg_stat_statements,aurora_optimized_reads_cache ``` ## 使用 Aurora Optimized Reads 當您使用其中一個 NVMe 型資料庫執行個體佈建 Aurora PostgreSQL 資料庫執行個體時，資料庫執行個體會自動使用 Aurora Optimized Reads。若要開啟 Aurora Optimized Reads，請執行下列其中一項： + 使用其中一個 NVMe 型資料庫執行個體類別，建立 Aurora PostgreSQL 資料庫叢集。如需詳細資訊，請參閱[建立 Amazon Aurora 資料庫叢集](Aurora.CreateInstance.md)。 + 修改現有的 Aurora PostgreSQL 資料庫叢集，以使用其中一個 NVMe 型資料庫執行個體類別。如需詳細資訊，請參閱[修改 Amazon Aurora 資料庫叢集](Aurora.Modifying.md)。 Aurora Optimized Reads 適用於支援 AWS 區域一或多個具有本機 NVMe SSD 儲存體的資料庫執行個體類別的所有。如需詳細資訊，請參閱[Amazon Aurora 資料庫執行個體類別](Concepts.DBInstanceClass.md)。若要切換回非 Optimized Reads Aurora 執行個體，請將 Aurora 執行個體的資料庫執行個體類別修改為針對資料庫工作負載沒有 NVMe 暫時性儲存的類似執行個體類別。例如，如果目前的資料庫執行個體類別是 db.r6gd.4xlarge，請選擇 db.r6g.4xlarge 以切換回來。如需詳細資訊，請參閱[修改 Aurora 資料庫執行個體](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html)。 ## Aurora Optimized Reads 的使用案例 **啟用 Optimized Reads 的階層式快取** 下列是一些可從 Optimized Reads 搭配階層式快取受益的使用案例： + 具有嚴格效能 SLA 的網際網路規模的應用程式，例如支付處理、計費、電子商務。 + 執行數百個點查詢以便收集指標/資料的即時報告儀表板。 + 具有 pgvector 擴充功能的生成式 AI 應用程式可以在數百萬個向量嵌入中搜尋精確或最近的鄰居。 **啟用 Optimized Reads 的暫存物件** 下列是一些可從 Optimized Reads 搭配暫存物件受益的使用案例： + 分析查詢，包括一般資料表表達式 (CTE)、衍生資料表和群組操作。 + 處理應用程式未最佳化查詢的僅供讀取複本。 + 具有複雜操作的隨需或動態報告查詢 (例如 GROUP BY 和 ORDER BY)，無法始終使用適當的索引。 + 用於排序的 `CREATE INDEX` 或 `REINDEX` 操作。 + 使用內部暫存資料表的其他工作負載 ## 監控使用 Aurora Optimized Reads 的資料庫執行個體您可以使用 EXPLAIN 命令監控使用啟用 Optimized Reads 之階層式快取的查詢，如以下範例所示： ``` Postgres=> EXPLAIN (ANALYZE, BUFFERS) SELECT c FROM sbtest15 WHERE id=100000000 QUERY PLAN -------------------------------------------------------------------------------------- Index Scan using sbtest15_pkey on sbtest15 (cost=0.57..8.59 rows=1 width=121) (actual time=0.287..0.288 rows=1 loops=1) Index Cond: (id = 100000000) Buffers: shared hit=3 read=2 aurora_orcache_hit=2 I/O Timings: shared/local read=0.264 Planning: Buffers: shared hit=33 read=6 aurora_orcache_hit=6 I/O Timings: shared/local read=0.607 Planning Time: 0.929 ms Execution Time: 0.303 ms (9 rows) Time: 2.028 ms ``` **注意** 只有在 Optimized Reads 已開啟且其值大於零時，才會顯示解釋計畫 `Buffers` 區段中的 `aurora_orcache_hit` 和 `aurora_storage_read` 欄位。讀取欄位是 `aurora_orcache_hit` 和 `aurora_storage_read` 欄位的總計。您可以透過下列 CloudWatch 指標，監控使用 Aurora Optimized Reads 的資料庫執行個體： + `AuroraOptimizedReadsCacheHitRatio` + `FreeEphemeralStorage` + `ReadIOPSEphemeralStorage` + `ReadLatencyEphemeralStorage` + `ReadThroughputEphemeralStorage` + `WriteIOPSEphemeralStorage` + `WriteLatencyEphemeralStorage` + `WriteThroughputEphemeralStorage` 這些指標提供可用執行個體儲存體、IOPS 和輸送量的相關資料。如需這些指標的詳細資訊，請參閱 [Amazon Aurora 的執行個體層級指標](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。您也可以使用 `pg_proctab` 擴充功能來監控 NVMe 儲存體。 ``` postgres=>select * from pg_diskusage(); major | minor | devname | reads_completed | reads_merged | sectors_read | readtime | writes_completed | writes_merged | sectors_written | writetime | current_io | iotime | totaliotime ------+-------+---------------------+-----------------+--------------+--------------+----------+------------------+---------------+-----------------+-----------+------------+---------+------------- | | rdstemp | 23264 | 0 | 191450 | 11670 | 1750892 | 0 | 24540576 | 819350 | 0 | 3847580 | 831020 | | rdsephemeralstorage | 23271 | 0 | 193098 | 2620 | 114961 | 0 | 13845120 | 130770 | 0 | 215010 | 133410 (2 rows) ``` ## Aurora Optimized Reads 的最佳實務請使用 Aurora Optimized Reads 的下列最佳實務： + 使用 CloudWatch 指標 `FreeEphemeralStorage` 監控執行個體儲存體上的可用儲存空間。如果執行個體儲存體由於資料庫執行個體的工作負載而達到其限制，請調整大量使用暫存物件的並行和查詢，或修改它以使用較大的資料庫執行個體類別。 + 監控 CloudWatch 指標以了解 Optimized Reads 快取命中率。像 VACUUM 這樣的操作可以非常快速地修改大量區塊。這可能會造成命中率暫時下降。`pg_prewarm` 擴充功能可用來將資料載入緩衝區快取，讓 Aurora 主動將其中一些區塊寫入 Optimized Reads 快取。 + 您可以啟用叢集快取管理 (CCM)，預熱第 0 層讀取器上的緩衝區快取和階層式快取，這將用作容錯移轉目標。啟用 CCM 時，會定期掃描緩衝區快取，以便在階層式快取中寫入符合移出資格的頁面。如需 CCM 的詳細資訊，請參閱 [Aurora PostgreSQL 的容錯移轉後使用叢集快取管理快速復原](AuroraPostgreSQL.cluster-cache-mgmt.md)。 # 最佳化 Aurora PostgreSQL 中的相互關聯子查詢關聯的子查詢會參考外部查詢中的資料表資料欄。它會針對外部查詢傳回的每個資料列評估一次。在下列範例中，子查詢參考資料表 ot 中的資料欄。此資料表不包含在子查詢的 FROM 子句中，但會在外部查詢的 FROM 子句中參考。如果資料表 ot 有 100 萬個資料列，則需要評估 100 萬次子查詢。 ``` SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); ``` **注意** 從 16.8 版開始，Aurora PostgreSQL 提供子查詢轉換和子查詢快取，而 Babelfish for Aurora PostgreSQL 支援 4.2.0 版的這些功能。從 Babelfish for Aurora PostgreSQL 4.6.0 和 5.2.0 版開始，下列參數控制這些功能： babelfishpg\$1tsql.apg\$1enable\$1correlated\$1scalar\$1transform babelfishpg\$1tsql.apg\$1enable\$1subquery\$1cache 這兩個參數預設會開啟。 ## 使用子查詢轉換改善 Aurora PostgreSQL 查詢效能 Aurora PostgreSQL 可以透過將相互關聯子查詢轉換為同等外部聯結來加速相互關聯子查詢。此最佳化適用於下列兩種相互關聯的子查詢類型： + 傳回單一彙總值並出現在 SELECT 清單中的子查詢。 ``` SELECT ot.a, ot.b, (SELECT AVG(it.b) FROM it WHERE it.a = ot.a) FROM ot; ``` + 傳回單一彙總值並出現在 WHERE 子句中的子查詢。 ``` SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); ``` ### 在子查詢中啟用轉換若要啟用相互關聯子查詢轉換為同等外部聯結，請將 `apg_enable_correlated_scalar_transform` 參數設定為 `ON`。此參數的預設值為 `OFF`。您可以修改叢集或執行個體參數群組以設定這些參數。如需詳細資訊，請參閱 [Amazon Aurora 的參數群組](USER_WorkingWithParamGroups.md)。或者，您也可以使用下列命令，為目前工作階段進行設定： ``` SET apg_enable_correlated_scalar_transform TO ON; ``` ### 確認轉換使用 EXPLAIN 命令來確認相互關聯的子查詢是否已轉換為查詢計劃中的外部聯結。啟用轉換時，適用的相互關聯子查詢部分會轉換為外部聯結。例如： ``` postgres=> CREATE TABLE ot (a INT, b INT); CREATE TABLE postgres=> CREATE TABLE it (a INT, b INT); CREATE TABLE postgres=> SET apg_enable_correlated_scalar_transform TO ON; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); QUERY PLAN -------------------------------------------------------------- Hash Join Hash Cond: (ot.a = apg_scalar_subquery.scalar_output) Join Filter: ((ot.b)::numeric < apg_scalar_subquery.avg) -> Seq Scan on ot -> Hash -> Subquery Scan on apg_scalar_subquery -> HashAggregate Group Key: it.a -> Seq Scan on it ``` 當 GUC 參數切換為 `OFF` 時，不會轉換相同的查詢。計劃不會有外部聯結，而是子計劃。 ``` postgres=> SET apg_enable_correlated_scalar_transform TO OFF; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); QUERY PLAN ---------------------------------------- Seq Scan on ot Filter: ((b)::numeric < (SubPlan 1)) SubPlan 1 -> Aggregate -> Seq Scan on it Filter: (a = ot.a) ``` ### 限制 + 子查詢必須位於 SELECT 清單或 WHERE 子句中的其中一個條件。否則，將不會進行轉換。 + 子查詢必須傳回彙總函數。不支援使用者定義的彙總函數進行轉換。 + 傳回運算式不是簡單彙總函數的子查詢將不會轉換。 + 子查詢 WHERE 子句中的相互關聯條件應該是簡單的資料欄參考。否則，將不會進行轉換。 + 子查詢中的相互關聯條件，其中子句必須是純等式述詞。 + 子查詢不能包含 HAVING 或 GROUP BY 子句。 + 子查詢中的 WHERE 子句可能包含一或多個與 AND 結合的述詞。 **注意** 轉換的效能影響取決於您的結構描述、資料和工作負載。隨著外部查詢產生的資料列數增加，轉換的相互關聯子查詢執行可以大幅改善效能。強烈建議您在非生產環境中使用實際結構描述、資料和工作負載測試此功能，然後再在生產環境中啟用此功能。 ## 使用子查詢快取來改善 Aurora PostgreSQL 查詢效能 Aurora PostgreSQL 支援子查詢快取，以存放相互關聯子查詢的結果。當子查詢結果已在快取中時，此功能會略過重複的相會關聯子查詢執行。 ### 了解子查詢快取 PostgreSQL 的記憶節點是子查詢快取的關鍵部分。記憶節點會在本機快取中維護雜湊資料表，以從輸入參數值映射至查詢結果列。雜湊資料表的記憶體限制是 work\$1mem 和 hash\$1mem\$1multiplier 的乘積。若要進一步了解，請參閱[資源耗用](https://www.postgresql.org/docs/16/runtime-config-resource.html)。在查詢執行期間，子查詢快取會使用快取命中率 (CHR) 來估計快取是否改善查詢效能，並在查詢執行時間決定是否繼續使用快取。CHR 是快取命中次數與請求總數的比率。例如，如果相互關聯子查詢需要執行 100 次，而且可以從快取擷取其中 70 個執行結果，則 CHR 為 0.7。對於每個快取遺漏的 apg\$1subquery\$1cache\$1check\$1interval 數量，檢查 CHR 是否大於 apg\$1subquery\$1cache\$1hit\$1rate\$1threshold 來評估子查詢快取的優點。如果沒有，快取將從記憶體中刪除，而查詢執行將返回原始、未快取的子查詢重新執行。 ### 控制子查詢快取行為的參數下表列出控制子查詢快取行為的參數。 | 參數 | 描述 | 預設 | 允許 | | --- | --- | --- | --- | | apg\$1enable\$1subquery\$1cache | 啟用相互關聯純量子查詢的快取使用。 | OFF | ON、OFF | | apg\$1subquery\$1cache\$1check\$1interval | 設定快取未命中次數的頻率，以評估子查詢快取命中率。 | 500 | 0–2147483647 | | apg\$1subquery\$1cache\$1hit\$1rate\$1threshold | 設定子查詢快取命中率的閾值。 | 0.3 | 0.0–1.0 | **注意** 較大的 `apg_subquery_cache_check_interval` 值可能會改善 CHR 型快取效益估算的準確性，但會增加快取負荷，因為快取資料表有 `apg_subquery_cache_check_interval` 資料列之前，CHR 不會進行評估。較大的 `apg_subquery_cache_hit_rate_threshold` 偏差值會捨棄子查詢快取，並返回原始、未快取的子查詢重新執行。您可以修改叢集或執行個體參數群組以設定這些參數。如需詳細資訊，請參閱 [Amazon Aurora 的參數群組](USER_WorkingWithParamGroups.md)。或者，您也可以使用下列命令，為目前工作階段進行設定： ``` SET apg_enable_subquery_cache TO ON; ``` ### 在 Aurora PostgreSQL 中開啟子查詢快取啟用子查詢快取時，Aurora PostgreSQL 會套用快取來儲存子查詢結果。然後，查詢計劃在 SubPlan 下會有記憶節點。例如，下列命令序列顯示沒有子查詢快取之簡單相互關聯子查詢的預估查詢執行計劃。 ``` postgres=> SET apg_enable_subquery_cache TO OFF; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ------------------------------------ Seq Scan on ot Filter: (b < (SubPlan 1)) SubPlan 1 -> Seq Scan on it Filter: (a = ot.a) ``` 開啟 `apg_enable_subquery_cache` 後，查詢計劃會在 SubPlan 節點下包含記憶節點，表示子查詢打算使用快取。 ``` postgres=> SET apg_enable_subquery_cache TO ON; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ------------------------------------ Seq Scan on ot Filter: (b < (SubPlan 1)) SubPlan 1 -> Memoize Cache Key: ot.a Cache Mode: binary -> Seq Scan on it Filter: (a = ot.a) ``` 實際查詢執行計劃包含子查詢快取的更多詳細資訊，包括快取命中和快取遺漏。下列輸出顯示將一些值插入資料表後，上述範例查詢的實際查詢執行計劃。 ``` postgres=> EXPLAIN (COSTS FALSE, TIMING FALSE, ANALYZE TRUE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ----------------------------------------------------------------------------- Seq Scan on ot (actual rows=2 loops=1) Filter: (b < (SubPlan 1)) Rows Removed by Filter: 8 SubPlan 1 -> Memoize (actual rows=0 loops=10) Cache Key: ot.a Cache Mode: binary Hits: 4 Misses: 6 Evictions: 0 Overflows: 0 Memory Usage: 1kB -> Seq Scan on it (actual rows=0 loops=6) Filter: (a = ot.a) Rows Removed by Filter: 4 ``` 快取命中總數為 4，快取未命中總數為 6。如果命中和未命中總數少於記憶節點中的迴圈數目，表示 CHR 評估未通過，且快取已在某個時間點清除和捨棄。子查詢執行接著會返回原始未快取的重新執行。 ### 限制子查詢快取不支援相互關聯子查詢的特定模式。即使子查詢快取已開啟，仍會在沒有快取的情況下執行這些類型的查詢： + IN/EXISTS/ANY/ALL 相互關聯子查詢 + 包含非確定性函數的相互關聯子查詢。 + 參考資料類型不支援雜湊或相等操作之外部資料表資料欄的相互關聯子查詢。 # 使用調適型聯結改善查詢效能 ## 概觀調適型聯結是 Aurora PostgreSQL 17.4 中的預覽功能，有助於改善查詢效能。此功能預設為停用，但您可以使用全域使用者組態 (GUC) 參數來啟用此功能。由於這是預覽功能，預設參數值可能會變更。啟用時，調適型聯結可透過在執行階段從巢狀迴圈聯結動態切換到雜湊聯結，協助最佳化查詢效能。當 PostgreSQL 最佳化工具因為不正確的基數預估而不正確地選擇巢狀迴圈聯結時，就會發生此切換。 ## 設定調適型聯結您可以使用這三個 GUC 參數來控制調適型聯結： **調適型聯結組態參數** | GUC 參數 | Description | 預設值和組態選項 | | --- | --- | --- | | apg\$1adaptive\$1join\$1crossover\$1multiplier | 此乘數可與資料列交叉點搭配使用，以判斷何時從巢狀迴圈切換到雜湊聯結。資料列交叉點是 SQL 最佳化工具預估巢狀迴圈和雜湊聯結操作具有相同成本的位置。較高的乘數值可降低調適型聯結切換到雜湊聯結的可能性。 | 控制是否已啟用調適型聯結 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) | | apg\$1adaptive\$1join\$1cost\$1threshold | 此參數會設定最低查詢成本閾值。對於低於此閾值的查詢，調適型聯結會自行自動停用。這可避免簡單查詢的效能額外負荷，其中規劃調適型聯結的成本可能會超過從巢狀迴圈切換到雜湊聯結的優勢。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) | | apg\$1enable\$1parameterized\$1adaptive\$1join | 此參數會在啟用時，將調適型聯結功能延伸至參數化巢狀迴圈聯結。根據預設，調適型聯結僅適用於未參數化巢狀迴圈聯結，因為這些聯結更可能因為切換到雜湊聯結而獲益。參數化巢狀迴圈聯結通常效能更佳，因此切換到雜湊聯結較不重要。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) 需要先啟用 `apg_adaptive_join_crossover_multiplier` | # 使用共用計劃快取 ## 概觀 Aurora PostgreSQL 使用process-per-user模型，其中每個用戶端連線都會建立專用的後端程序。每個後端程序都會針對預備陳述式維護自己的本機計劃快取。由於這些快取無法在程序之間共用，因此使用許多預備陳述式的應用程式可能會在不同的後端程序中建立重複的快取，進而增加記憶體用量。 Aurora PostgreSQL 17.6 版和更新版本以及 16.10 版和更新版本推出共用計劃快取功能。當您啟用此功能時，後端程序可以共用一般計劃，從而減少記憶體用量，並透過消除重複的計劃產生來改善效能。共用計劃快取使用下列元件做為其快取金鑰： + 查詢字串（包括註解） + 規劃人員相關的 GUC 參數（包括 `search_path`) + 使用者 ID + 資料庫 ID 執行個體重新啟動會重設共用快取。 ## Parameters 下表說明控制共用計劃快取功能的參數： | 參數 | 描述 | 預設 | 允許 | | --- | --- | --- | --- | | apg\$1shared\$1plan\$1cache.enable | 開啟或關閉共用計劃快取 | 0 （關閉） | 0, 1 | | apg\$1shared\$1plan\$1cache.max | 快取項目的數量上限 | 200–1000 （視執行個體大小而定） | 100–50000 | | apg\$1shared\$1plan\$1cache.min\$1size\$1per\$1entry | 在共用快取中存放的計劃大小下限。較小的計劃使用本機快取來最佳化 OLTP 效能。 | 16 KB | 0–32768 (KB) | | apg\$1shared\$1plan\$1cache.max\$1size\$1per\$1entry | 共用快取的計劃大小上限。較大的計劃只會存放成本資訊。 | 256 KB–4 MB （視執行個體大小而定） | 0–32768 (KB) | | apg\$1shared\$1plan\$1cache.idle\$1generic\$1plan\$1release\$1timeout | 閒置工作階段發佈本機一般計劃的時間。較低的值可節省記憶體；較高的值可能會改善效能。 | 10 秒 | 0–2147483647 （毫秒） | **注意** 您可以修改所有參數，而無需重新啟動。 ## 監控檢視和函數 + `apg_shared_plan_cache()` – 顯示詳細的快取項目資訊（命中、有效性、時間戳記） + `apg_shared_plan_cache_stat()` – 顯示執行個體層級統計資料（移出、失效） + `apg_shared_plan_cache_reset()` – 移除 `apg_shared_plan_cache()`和中的所有項目 `apg_shared_plan_cache_stat()` + `apg_shared_plan_cache_remove(cache_key)` – 從項目符合 `apg_shared_plan_cache()`的項目中移除項目 `cache_key` ## 限制 + 僅適用於預備陳述式，不會快取 PL/pgSQL 陳述式 + 不會快取包含暫存資料表或目錄資料表的查詢 + 不會快取依賴 RLS 的查詢（資料列層級安全性） + 每個複本都會維護自己的快取（無跨複本共用）