PostgreSQL 的 VACUUM 命令需要定期處理每個表，原因如下：

這些原因中的每一個都決定了執行不同頻率和範圍的 VACUUM 操作，如以下小節所述。

VACUUM 有兩個變體：標準 VACUUM 和 VACUUM FULL。 VACUUM FULL 可以回收更多磁碟空間，但執行速度慢得多。此外，標準形式的 VACUUM 可以與生產資料庫操作並行執行。（諸如 SELECT、INSERT、UPDATE 和 DELETE 等命令將繼續正常工作，但當表被清理時，您將無法使用諸如 ALTER TABLE 等命令修改表的定義。） VACUUM FULL 需要對正在處理的表進行 ACCESS EXCLUSIVE 鎖，因此無法與其他表的使用並行進行。因此，通常情況下，管理員應努力使用標準 VACUUM 並避免 VACUUM FULL。

VACUUM 會產生大量的 I/O 流量，這可能導致其他活動會話的效能下降。有一些配置引數可以調整以減少後臺清理的效能影響 — 請參閱第 19.10.2 節。

在 PostgreSQL 中，行的 UPDATE 或 DELETE 操作不會立即刪除行的舊版本。此方法對於獲得多版本併發控制 (MVCC) 的好處是必需的（MVCC參見第 13 章）：只要行版本仍然可能對其他事務可見，就不能刪除它。但最終，過時或已刪除的行版本將不再被任何事務關注。然後必須回收它佔用的空間以供新行重用，以避免磁碟空間需求的無限增長。這透過執行 VACUUM 來完成。

標準形式的 VACUUM 會移除表和索引中的死行版本，並將空間標記為可供將來重用。但是，它不會將空間返回給作業系統，除非在一種特殊情況下，即表中一個或多個頁面完全變為空閒，並且可以輕鬆獲取排他性表鎖。相反，VACUUM FULL 透過寫入一個沒有死空間的完整的新表文件版本來主動壓縮表。這最小化了表的大小，但可能需要很長時間。它還為新表副本需要額外的磁碟空間，直到操作完成。

例行清理的通常目標是足夠頻繁地執行標準 VACUUM 操作，以避免需要 VACUUM FULL。自動清理守護程序試圖以這種方式工作，事實上，它永遠不會發出 VACUUM FULL。在此方法中，其思想不是將表保持在其最小尺寸，而是保持穩定的磁碟空間使用：每個表佔用的空間相當於其最小尺寸加上清理執行之間使用的空間。雖然 VACUUM FULL 可用於將表縮小回其最小尺寸並向作業系統返回磁碟空間，但如果表將來會再次增長，那麼這樣做意義不大。因此，對於維護大量更新的表，中等頻率的標準 VACUUM 執行比不頻繁的 VACUUM FULL 執行更好。

一些管理員更喜歡自己安排清理，例如在低負載的夜間完成所有工作。根據固定時間表進行清理的困難在於，如果一個表意外地更新活動激增，它可能會變得腫脹到實際上需要 VACUUM FULL 來回收空間。使用自動清理守護程序可以緩解這個問題，因為守護程序會根據更新活動動態地安排清理。除非您有高度可預測的工作負載，否則完全停用守護程序是不明智的。一種可能的折衷是設定守護程序的引數，使其僅對異常重的更新活動做出響應，從而防止事情失控，而計劃的 VACUUM 操作則負責在典型負載下完成大部分工作。

對於不使用自動清理的管理員來說，一種典型的方法是在低使用期安排每天一次資料庫範圍的 VACUUM，並根據需要補充對大量更新的表的更頻繁的清理。（一些更新率極高的安裝會像每隔幾分鐘一樣頻繁地清理其最繁忙的表。）如果您在一個叢集中有多個數據庫，請不要忘記 VACUUM 每個資料庫；程式 vacuumdb 可能會有所幫助。

為了生成良好的查詢計劃，PostgreSQL 查詢最佳化器依賴於表內容的統計資訊。這些統計資訊由 ANALYZE 命令收集，該命令可以單獨呼叫，也可以作為 VACUUM 的可選步驟。擁有相對準確的統計資訊很重要，否則糟糕的計劃選擇可能會降低資料庫效能。

如果啟用了自動清理守護程序，它將在表內容發生足夠大的變化時自動發出 ANALYZE 命令。但是，管理員可能更喜歡依賴手動計劃的 ANALYZE 操作，特別是當已知對錶的更新活動不會影響“有趣”列的統計資訊時。守護程序嚴格地將 ANALYZE 的計劃安排為插入或更新的行數的一個函式；它不知道這是否會導致有意義的統計變化。

分割槽和繼承子表中的元組更改不會觸發父表的分析。如果父表為空或很少更改，它可能永遠不會被自動清理處理，並且繼承樹整體的統計資訊也不會被收集。因此，有必要手動執行 ANALYZE 來保持統計資訊最新。

與清理空間回收一樣，對於大量更新的表，頻繁更新統計資訊比很少更新的表更有用。但即使對於大量更新的表，如果資料的統計分佈變化不大，也可能不需要更新統計資訊。一個簡單的經驗法則是考慮表中列的最小值和最大值變化的程度。例如，包含行更新時間的 timestamp 列將隨著行的新增和更新而具有不斷增加的最大值；這樣的列可能比包含網站訪問頁面 URL 的列需要更頻繁的統計資訊更新。URL 列可能接收相同的更改頻率，但其值的統計分佈可能變化相對緩慢。

可以對特定表甚至表的特定列執行 ANALYZE，因此如果您的應用程式需要，可以提供更頻繁地更新某些統計資訊的靈活性。但在實踐中，最好只分析整個資料庫，因為它是一個快速操作。ANALYZE 使用表中行的統計隨機樣本，而不是讀取每一行。

清理程式為每個表維護一個可見性圖，以跟蹤哪些頁面僅包含已知對所有活動事務（以及直到頁面再次被修改之前的所有未來事務）可見的元組。這有兩個目的。首先，清理程式本身可以在下一次執行時跳過這些頁面，因為沒有什麼需要清理。

其次，它允許 PostgreSQL 僅使用索引回答某些查詢，而不引用底層表。由於 PostgreSQL 索引不包含元組可見性資訊，因此正常索引掃描會為每個匹配的索引條目獲取堆元組，以檢查它是否應該被當前事務看到。另一方面，僅索引掃描會先檢查可見性圖。如果已知頁面上的所有元組都可見，則可以跳過堆提取。這在可見性圖可以防止磁碟訪問的大型資料集上非常有用。可見性圖遠小於堆，因此即使堆非常大，它也可以輕鬆快取。

PostgreSQL 的MVCC事務語義依賴於能夠比較事務 ID（XID）編號：插入 XID 大於當前事務 XID 的行版本是“未來”的，並且不應對當前事務可見。但是，由於事務 ID 的大小有限（32 位），長時間執行（超過 40 億次事務）的叢集將遭受事務 ID 迴繞：XID 計數器迴繞到零，並且突然間曾經過去的事務現在看起來像是未來的事務——這意味著它們的結果變得不可見。簡而言之，災難性的資料丟失。（實際上資料仍然存在，但如果您無法訪問它，那也無濟於事。）為了避免這種情況，必須至少每 20 億次事務清理每個資料庫中的每個表。

定期清理可以解決問題的原因為 VACUUM 會將行標記為凍結，表示它們是由已提交的足夠遠的事務插入的，以至於插入事務的效果肯定對所有當前和未來的事務都可見。正常 XID 使用模 2³² 算術進行比較。這意味著對於每個正常 XID，都有 20 億個 XID 比它“舊”，另外 20 億個 XID 比它“新”；換句話說，正常 XID 空間是迴圈的，沒有端點。因此，一旦建立了一個具有特定正常 XID 的行版本，該行版本在接下來的 20 億次事務中都會顯得“過去”，無論我們指的是哪個正常 XID。如果該行版本在超過 20 億次事務後仍然存在，它將突然顯得“未來”。為了防止這種情況，PostgreSQL 保留了一個特殊的 XID，FrozenTransactionId，它不遵循正常的 XID 比較規則，並且始終被認為比任何正常 XID 都舊。凍結的行版本被視為好像插入 XID 是 FrozenTransactionId，因此無論它們存在多久，它們對所有正常事務都會顯得“過去”，並且不受迴繞問題的影響。因此，這些行版本將保持有效，直到被刪除，無論那需要多久。

vacuum_freeze_min_age 控制 XID 值需要多舊才能凍結帶有該 XID 的行。增加此設定可能會避免不必要的工作，如果原本要凍結的行很快就會被修改，但減少此設定會增加表在必須再次清理之前可以經過的事務數。

VACUUM 使用可見性圖來確定必須掃描表的哪些頁面。通常，即使這些頁面可能仍包含具有舊 XID 值的行版本，它也會跳過沒有任何死行版本的頁面。因此，常規 VACUUM 不會始終凍結表中的所有舊行版本。當這種情況發生時，VACUUM 最終需要執行強制清理，它將凍結所有符合條件的未凍結 XID 和 MXID 值，包括那些來自全部可見但並非全部凍結的頁面。

如果一個表正在累積一個所有頁面都可見但並非所有頁面都凍結的積壓，一個常規清理可能會選擇掃描可跳過的頁面以嘗試凍結它們。這樣做會減少下一次強制清理必須掃描的頁面數量。這些被稱為急切掃描的頁面。可以透過增加 vacuum_max_eager_freeze_failure_rate 來調整急切掃描，以嘗試凍結更多所有頁面都可見的頁面。即使急切掃描已將所有頁面可見但並非全部凍結的頁面數量降至最低，大多數表仍需要定期強制清理。但是，任何成功急切凍結的頁面都可以在強制清理期間被跳過，因此急切凍結可能會最小化強制清理的開銷。

vacuum_freeze_table_age 控制何時強制清理一個表。如果自上次此類掃描以來經過的事務數大於 vacuum_freeze_table_age 減去 vacuum_freeze_min_age，則掃描所有頁面可見但並非全部凍結的頁面。將 vacuum_freeze_table_age 設定為 0 會強制 VACUUM 始終使用其強制策略。

一個表可以不被清理的最長時間是 20 億個事務減去上次強制清理時的 vacuum_freeze_min_age 值。如果它超過這個時間未被清理，可能會導致資料丟失。為了確保這種情況不會發生，當資料庫中最舊的 XID 距離迴繞點只有 autovacuum_freeze_max_age 事務時，就會自動呼叫 autovacuum。 (即使 autovacuum 被停用，這也會發生。)

這意味著，如果一個表沒有被其他方式清理，它將在大約每 autovacuum_freeze_max_age 減去 vacuum_freeze_min_age 個事務後呼叫 autovacuum。對於定期因空間回收而清理的表來說，這無關緊要。然而，對於靜態表（包括接收插入但沒有或幾乎沒有更新或刪除操作的表），則不需要為了回收空間而進行清理，因此嘗試最大化強制 autovacuum 對非常大的靜態表的間隔是有益的。顯然，可以透過增加 autovacuum_freeze_max_age 或減少 vacuum_freeze_min_age 來實現這一點。

vacuum_freeze_table_age 的有效最大值是 0.95 * autovacuum_freeze_max_age；大於此值的設定將被限制為最大值。大於 autovacuum_freeze_max_age 的值沒有意義，因為到那時將觸發一個反迴繞 autovacuum，並且 0.95 的乘數留有一些緩衝空間，可以在此之前執行手動 VACUUM。經驗法則規定，vacuum_freeze_table_age 應設定為略低於 autovacuum_freeze_max_age 的值，留出足夠的間隔，以便一個定期計劃的 VACUUM 或由正常刪除和更新活動觸發的 autovacuum 在此視窗中執行。將其設定得太近可能會導致反迴繞 autovacuum，即使表最近被清理以回收空間，而較低的值會導致更頻繁的強制清理。

增加 autovacuum_freeze_max_age (以及 vacuum_freeze_table_age) 的唯一缺點是 pg_xact 和 pg_commit_ts 子目錄的資料庫叢集將佔用更多空間，因為它必須儲存從 autovacuum_freeze_max_age 範圍回溯到所有事務的提交狀態（如果啟用了 track_commit_timestamp）和時間戳。提交狀態每個事務使用兩位，因此如果 autovacuum_freeze_max_age 設定為其允許的最大值 20 億，那麼 pg_xact 預計會增長到大約半個 GB，而 pg_commit_ts 會增長到大約 20GB。如果這與您的總資料庫大小相比微不足道，則建議將 autovacuum_freeze_max_age 設定為其允許的最大值。否則，根據您願意為 pg_xact 和 pg_commit_ts 儲存分配多少空間來設定它。（預設值 2 億事務，相當於大約 50MB 的 pg_xact 儲存和大約 2GB 的 pg_commit_ts 儲存。）

減少 vacuum_freeze_min_age 的一個缺點是它可能會導致 VACUUM 做無用功：如果行很快被修改（導致它獲得新的 XID），那麼凍結行版本就是浪費時間。因此，設定應該足夠大，以至於行不太可能再次更改。

為了跟蹤資料庫中最舊未凍結 XID 的年齡，VACUUM 將 XID 統計資訊儲存在系統表 pg_class 和 pg_database 中。特別是，表 pg_class 行的 relfrozenxid 列包含在上次成功推進 relfrozenxid 的 VACUUM（通常是上次強制 VACUUM）結束時仍然存在的​​最舊未凍結 XID。類似地，資料庫 pg_database 行的 datfrozenxid 列是該資料庫中出現的未凍結 XID 的下界 — 它只是資料庫中每個表 relfrozenxid 值的最小值。檢查此資訊的便捷方法是執行如下查詢：

SELECT c.oid::regclass as table_name,
       greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age
FROM pg_class c
LEFT JOIN pg_class t ON c.reltoastrelid = t.oid
WHERE c.relkind IN ('r', 'm');

SELECT datname, age(datfrozenxid) FROM pg_database;

age 列測量從截止 XID 到當前事務 XID 的事務數。

雖然 VACUUM 主要掃描自上次清理以來已修改的頁面，但它也可能急切地掃描一些所有頁面都可見但並非全部凍結的頁面，試圖凍結它們，但 relfrozenxid 僅在掃描完表中可能包含未凍結 XID 的每個頁面後才會被推進。當 relfrozenxid 比 vacuum_freeze_table_age 事務舊時，當使用 VACUUM 的 FREEZE 選項時，或者當所有尚未全部凍結的頁面碰巧需要清理以移除死行版本時，就會發生這種情況。當 VACUUM 掃描表中所有尚未全部凍結的頁面時，它應該將 age(relfrozenxid) 設定為一個略大於 vacuum_freeze_min_age 設定的值（更多的是自 VACUUM 開始以來啟動的事務數）。VACUUM 會將 relfrozenxid 設定為表中剩餘的最舊 XID，因此最終值可能比嚴格要求的要新得多。如果在表中未發出 relfrozenxid 推進的 VACUUM 直到達到 autovacuum_freeze_max_age，那麼很快就會強制對該表進行 autovacuum。

如果由於某種原因 autovacuum 未能清除表中的舊 XID，當資料庫的最舊 XID 距離迴繞點還有 4000 萬事務時，系統將開始發出類似以下的警告訊息：

WARNING:  database "mydb" must be vacuumed within 39985967 transactions
HINT:  To avoid XID assignment failures, execute a database-wide VACUUM in that database.

(如提示所示，手動 VACUUM 應能解決問題；但請注意，VACUUM 應由超級使用者執行，否則它將無法處理系統目錄，這將阻止它能夠推進資料庫的 datfrozenxid。) 如果忽略這些警告，一旦距離迴繞只剩下三百萬事務，系統將拒絕分配新的 XID。

ERROR:  database is not accepting commands that assign new XIDs to avoid wraparound data loss in database "mydb"
HINT:  Execute a database-wide VACUUM in that database.

在此條件下，所有正在進行的事務都可以繼續，但只能啟動只讀事務。修改資料庫記錄或截斷關係的操作將失敗。VACUUM 命令仍然可以正常執行。請注意，與早期版本有時推薦的相反，在這種情況下，停止 postmaster 或進入單使用者模式以恢復正常操作是不必要的，也是不推薦的。相反，請按照以下步驟操作：

PostgreSQL 有一個可選但強烈推薦的功能，稱為自動清理，其目的是自動化 VACUUM 和 ANALYZE 命令的執行。啟用後，自動清理會檢查已插入、更新或刪除大量元組的表。這些檢查使用統計資訊收集設施；因此，除非 track_counts 設定為 true，否則無法使用自動清理。在預設配置中，自動清理是啟用的，並且相關的配置引數設定正確。

“自動清理守護程序”實際上由多個程序組成。有一個持久的守護程序，稱為自動清理啟動器，它負責為所有資料庫啟動自動清理工作程序。啟動器會將工作分配到一段時間內，並嘗試每 autovacuum_naptime 秒在每個資料庫中啟動一個工作程序。（因此，如果安裝中有N個數據庫，則每 autovacuum_naptime/N 秒將啟動一個新的工作程序。）最多允許 autovacuum_max_workers 個工作程序同時執行。如果需要處理的資料庫多於 autovacuum_max_workers 個，則下一個資料庫將在第一個工作程序完成後立即處理。每個工作程序將檢查其資料庫中的每個表，並在需要時執行 VACUUM 和/或 ANALYZE。log_autovacuum_min_duration 可以設定為監視自動清理工作程序的活動。

如果多個大表在短時間內都符合清理條件，則所有自動清理工作程序可能都會長時間忙於清理這些表。這將導致其他表和資料庫在工作程序可用之前無法被清理。在一個數據庫中執行的工作程序數量沒有限制，但工作程序會盡量避免重複其他工作程序已完成的工作。請注意，執行的工作程序數量不計入 max_connections 或 superuser_reserved_connections 的限制。

relfrozenxid 值比 autovacuum_freeze_max_age 事務舊的表總是會被清理（這也適用於那些透過儲存引數修改了 freeze max age 的表；見下文）。否則，如果自上次 VACUUM 以來廢棄的元組數量超過了“清理閾值”，則該表將被清理。清理閾值定義為：

vacuum threshold = Minimum(vacuum max threshold, vacuum base threshold + vacuum scale factor * number of tuples)

其中清理最大閾值是 autovacuum_vacuum_max_threshold，清理基本閾值是 autovacuum_vacuum_threshold，清理比例因子是 autovacuum_vacuum_scale_factor，元組數是 pg_class.reltuples。

如果自上次清理以來插入的元組數量超過了定義的插入閾值，則也會清理該表，該閾值定義為：

vacuum insert threshold = vacuum base insert threshold + vacuum insert scale factor * number of tuples

其中清理插入基本閾值是 autovacuum_vacuum_insert_threshold，清理插入比例因子是 autovacuum_vacuum_insert_scale_factor。此類清理可以允許表的部分被標記為所有可見，並允許元組被凍結，這可以減少後續清理所需的工作。對於接收 INSERT 操作但幾乎不接收 UPDATE/DELETE 操作的表，降低表的 autovacuum_freeze_min_age 可能會有益，因為這可以允許元組被更早的清理凍結。廢棄元組的數量和插入元組的數量從累積統計系統獲取；這是一個最終一致的計數，由每個 UPDATE、DELETE 和 INSERT 操作更新。如果表的 relfrozenxid 值比 vacuum_freeze_table_age 事務舊，則會執行強制清理以凍結舊元組並推進 relfrozenxid。

對於分析，使用類似的條件：閾值，定義為：

analyze threshold = analyze base threshold + analyze scale factor * number of tuples

與自上次 ANALYZE 以來插入、更新或刪除的總元組數進行比較。

分割槽表不直接儲存元組，因此不被自動清理處理。（自動清理會像其他表一樣處理表分割槽。）不幸的是，這意味著自動清理不會對分割槽表執行 ANALYZE，這可能導致引用分割槽表統計資訊的查詢計劃不佳。您可以透過在分割槽表首次填充時手動執行 ANALYZE，並在其分割槽中的資料分佈發生顯著變化時再次執行來解決此問題。

臨時表無法被自動清理訪問。因此，應透過會話 SQL 命令執行適當的清理和分析操作。

預設閾值和比例因子取自 postgresql.conf，但可以為每個表覆蓋它們（以及許多其他自動清理控制引數）；有關更多資訊，請參閱儲存引數。如果某個設定已透過表的儲存引數更改，則處理該表時將使用該值；否則將使用全域性設定。有關全域性設定的更多詳細資訊，請參閱第 19.10.1 節。

當多個工作程序執行時，自動清理成本延遲引數（請參閱第 19.10.2 節）會在所有執行的工作程序之間進行“平衡”，以便系統的總 I/O 影響與實際執行的工作程序數量無關。但是，處理具有已設定的每個表 autovacuum_vacuum_cost_delay 或 autovacuum_vacuum_cost_limit 儲存引數的表的任何工作程序都不會在平衡演算法中被考慮。

自動清理工作程序通常不會阻止其他命令。如果一個程序嘗試獲取與自動清理持有的 SHARE UPDATE EXCLUSIVE 鎖衝突的鎖，鎖獲取將中斷自動清理。有關衝突的鎖模式，請參閱表 13.2。但是，如果自動清理是為了防止事務 ID 迴繞（即 pg_stat_activity 檢視中的自動清理查詢名稱以 (to prevent wraparound) 結尾），則自動清理不會自動中斷。