本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
在 Amazon Aurora PostgreSQL 中管理高物件計數
雖然 PostgreSQL 限制是理論上的，但資料庫中具有極高的物件計數會對各種操作造成顯著的效能影響。本文件涵蓋數種常見的物件類型，當總計數過高時，可能會導致數種影響。
下表提供物件類型及其潛在影響的摘要：
關係
PostgreSQL 資料庫中的資料表數量沒有特定的硬性限制。理論限制非常高，但在資料庫設計期間需要記住其他實際限制。
- 影響：自動清空落後
-
與工作量相比，自動清空可能會難以跟上交易 ID 成長或資料表膨脹的情況。
建議的動作：調整自動清空有幾個因素，可以正確跟上指定數量的資料表和指定工作負載。如需如何判斷適當自動清空設定的建議 的最佳實務使用 PostgreSQL autovacuum 的最佳實務。使用 postgres_get_av_diag 公用程式來監控交易 ID 成長的問題。
- 影響：主要版本升級/pg_dump 和還原
-
Amazon RDS 在 pg_upgrade 執行期間使用「--link」選項，以避免必須複製資料檔案，結構描述中繼資料仍需要還原至新版本的資料庫。即使使用平行 pg_restore，如果有大量關聯，這也會增加停機時間。
- 影響：一般效能降低
-
由於目錄大小而降低的一般效能。每個資料表及其相關聯的資料欄都會新增至
pg_attribute，pg_class以及常用於一般資料庫操作的pg_depend資料表。不會顯示特定的等待事件，但共用緩衝區效率會受到影響。建議的動作：定期檢查這些特定資料表的資料表膨脹，並偶爾在這些特定資料表
VACUUM FULL上執行 。請注意，在目錄資料表VACUUM FULL上需要ACCESS EXCLUSIVE鎖定，這表示在操作完成之前，其他查詢都無法存取它們。
大約閾值：百萬
暫時資料表
使用暫存資料表對於測試資料或中繼結果很有用，而且是許多資料庫引擎中常見的模式。必須了解 PostgreSQL 中大量使用的影響，以避免某些陷阱。每個暫存資料表的建立和捨棄都會將資料列新增至系統目錄資料表，當資料表膨脹時，會導致一般效能問題。
- 影響：自動清空落後
-
暫時資料表不會由自動清空清空，但會在交易 IDs存在期間保留，若未移除，可能會導致包裝。
建議的動作：暫時資料表會在建立它們的工作階段期間持續運作，或可以手動捨棄。避免使用暫存資料表長時間執行交易的最佳實務，可防止這些資料表產生最大使用的交易 ID 成長。
- 影響：一般效能降低
-
由於目錄大小而降低的一般效能。當工作階段持續建立和捨棄暫存資料表時，它會新增至
pg_attribute，pg_class以及常用於一般資料庫操作的pg_depend資料表。不會顯示特定的等待事件，但共用緩衝區效率會受到影響。建議的動作：
定期檢查這些特定資料表的資料表膨脹，並偶爾在這些特定資料表
VACUUM FULL上執行 。請注意，在目錄資料表VACUUM FULL上需要ACCESS EXCLUSIVE鎖定，這表示在操作完成之前，其他查詢都無法存取它們。如果大量使用暫存資料表，在主要版本升級之前，強烈建議使用這些特定目錄資料表
VACUUM FULL的 ，以減少停機時間。
一般最佳實務：
使用常見的資料表表達式來產生中繼結果，以減少暫時資料表的使用。這些有時可能會使所需的查詢複雜化，但會消除上述影響。
使用
TRUNCATE命令來清除內容，而不是執行捨棄/建立步驟，以重複使用暫存資料表。這也會消除暫時資料表造成交易 ID 成長的問題。
大約閾值：數十萬
未記錄的資料表
未記錄的資料表可以提供效能提升，因為它們不會產生任何 WAL 資訊。必須仔細使用它們，因為它們在資料庫損毀復原期間不會提供任何耐用性，因為它們將被截斷。這是 PostgreSQL 中的昂貴操作，因為每個未記錄的資料表都是序列截斷的。雖然對少量未記錄的資料表而言，此操作速度很快，但當它們以千為單位編號時，它可以開始在啟動期間新增顯著的延遲。
- 影響：邏輯複寫
-
邏輯複寫通常不包含未記錄的資料表，包括藍/綠部署，因為邏輯複寫依賴 WAL 來擷取和傳輸變更。閱讀如何設定 Aurora PostgreSQL 以複寫未記錄資料表的詳細資訊。
- 影響：讀取器節點
-
您只能從 Aurora 資料庫叢集中的寫入器節點存取未記錄的資料表。如需完整詳細資訊，請參閱在 Aurora PostgreSQL 中使用未記錄的資料表。
一般最佳實務：
-
未記錄資料表在 Aurora PostgreSQL 中提供有限的效能優勢，因此請評估正常資料表是否更適當。 PostgreSQL
大約閾值：數千
分區
分割可以提高查詢效能並提供資料的邏輯組織。在理想情況下，會組織分割區，以便在查詢規劃和執行期間使用分割區剔除。使用太多分割區可能會對查詢效能和資料庫維護產生負面影響。應謹慎選擇如何分割資料表，因為查詢規劃和執行的效能可能會受到設計不佳的負面影響。如需分割的詳細資訊，請參閱 PostgreSQL 文件
- 影響：一般效能降低
-
有時，規劃時間額外負荷會增加，並解釋查詢的計劃會變得更加複雜，導致難以識別調校機會。對於 18 之前的 PostgreSQL 版本，具有高工作負載的許多分割區可能會導致
LWLock:LockManager等待。建議動作：判斷可讓您完成資料組織，同時提供效能查詢執行的分割區數量下限。
- 影響：維護複雜性
-
非常大量的分割區會導致維護困難，例如建立前和移除。自動清空會將分割區視為一般關係，且必須執行定期清除，因此需要足夠的工作者來完成任務。
建議的動作：
請確定您預先建立分割區，以便在需要新分割區 （例如，每月型分割區） 且舊分割區推出時，不會封鎖工作負載。
確保您有足夠的自動清空工作者，可執行所有分割區的正常清除維護。
大約閾值：數百
暫存檔案
與上述的暫存資料表不同，當複雜的查詢可能同時執行多個排序或雜湊操作時，PostgreSQL 會建立暫存檔案，每個操作會使用執行個體記憶體將結果儲存到 work_mem 參數中指定的值。當執行個體記憶體不足時，會建立暫存檔來儲存結果。如需檔案的詳細資訊，請參閱管理暫存檔案。如果您的工作負載產生大量這些檔案，可能會有幾項影響。
- 影響：FreeLocalStorage 耗用量
-
當查詢結果無法容納 work_mem 時，暫存檔案是 PostgreSQL 的必要部分。一般而言，這沒問題。不過，當工作負載廣泛使用時，表示大型查詢會持續執行，而您將觀察到 FreeLocalStorage 減少。如需詳細資訊，請參閱管理暫存檔案。
一般最佳實務：
使用 Performance Insights 監控您的暫存檔案用量。
調校正在產生重要暫存檔案的查詢，以查看是否可以減少暫存檔案的總數。
大約閾值：數千
序列
序列是用於在 PostgreSQL 中自動遞增資料欄的基礎物件，可提供資料的唯一性和金鑰。這些可用於個別資料表，在正常操作期間不會產生任何後果，但邏輯複寫除外。
在 PostgreSQL 中，邏輯複寫目前不會將序列的目前值複寫至任何訂閱者。若要進一步了解，請參閱 PostgreSQL 文件中的限制頁面
- 影響：延長切換時間
-
如果您計劃將 藍/綠部署用於任何類型的組態變更或升級，請務必了解大量序列對切換的影響。切換的最後一個階段之一將同步序列的目前值，如果有數千個，這將增加整體切換時間。
建議的動作：如果您的資料庫工作負載允許使用共用 UUID 而非sequence-per-table的方法，這會在切換期間減少同步步驟。
大約閾值：數千
大型物件
大型物件存放在名為 pg_largeobject 的單一系統資料表中。每個大型物件在系統資料表 pg_largeobject_metadata 中也有一個項目。這些物件的建立、修改和清除與標準關係截然不同。大型物件不會由自動清空處理，必須透過稱為 vacuumlo 的個別程序定期清理。如需管理大型物件的範例，請參閱使用 lo 模組管理大型物件。
- 影響：邏輯複寫
-
在邏輯複寫期間，目前不會在 PostgreSQL 中複寫大型物件。若要進一步了解，請參閱 PostgreSQL 文件中的限制頁面
。在藍色/綠色組態中，這表示藍色環境中的大型物件不會複寫至綠色環境。 - 影響：主要版本升級
-
如果有數百萬個大型物件，且執行個體無法在升級期間處理它們，則升級可能會耗盡記憶體並失敗。PostgreSQL 主要版本升級程序包含兩個大階段：透過 pg_dump 傾印結構描述，並透過 pg_restore 還原結構描述。如果您的資料庫有數百萬個大型物件，您需要確保您的執行個體在升級期間有足夠的記憶體來處理 pg_dump 和 pg_restore，並將其擴展到更大的執行個體類型。
一般最佳實務：
定期使用 vacuumlo 公用程式移除您可能擁有的任何孤立大型物件。
請考慮使用 BYTEA 資料類型，將大型物件存放在資料庫中。
大約閾值：百萬
大約閾值
本主題中提到的大約閾值僅用於提供特定資源可擴展程度的估計。它們代表一般範圍，其中所描述的影響變得更有可能，但實際行為取決於您的特定工作負載、執行個體大小和組態。雖然可能超過這些預估值，但必須遵守注意和維護，以避免列出的影響。
