每當PostgreSQL數據庫中的表中的行被更新或刪除時，死亡行會被遺留下來。VACUUM則會把它們除去來使空間能被重新利用。如果一個表沒有被清空，它會變得臃腫，浪費磁盤空間而且會降低順序表掃描的速度，而且在較小范圍內也會降低索引掃描的速度。

VACUUM命令只可以移除這些不再被需要的行版本（也被稱為元組）。如果被刪除事務的事務ID（存儲在xmax系統列中）比仍然活躍在PostgreSQL數據庫（或者共享表的整個集群）中最老的事務（xmin界限）更老，那么這個元組將不再被需要。

注意以下三種情況就可以抑制PostgreSQL集群中的xmin界限

1、 查找長時間運行的事務

我們可以查找長時間運行的事務，然后使用pg_terminate_backend()函數去終止阻礙VACUUM命令的數據庫會話。

2、 查找復制槽

復制槽是一種數據結構，它使PostgreSQL服務器免于丟棄備用服務器仍然需要的信息。如果復制被推遲或者備用服務器被關閉，復制槽就會阻止VACUUM命令刪除舊的行。

復制槽提供了一種自動化的方式來確保主服務器不移除WAL塊直到它們被所有的從服務器接收。而且主服務器即使當從服務器斷開連接時也不移除可能導致恢復沖突的行。

復制槽只保留已知所需數量的WAL塊而不是多于所需數量。

使用復制槽可以避免這個問題：在從服務器未連接的任意時間段內不提供保護。

我們可以使用pg_drop_replication_slot()函數去丟棄不需要的復制槽。

這種情況只會發生在當hot_standby_feedback參數設置為on時的物理復制中。如果是邏輯復制，那么會有一個相似的危險，但是只有系統目錄會被影響。

3、查找準備好的事務

二階段提交協議是一種原子性確認協議。它是一種分布式算法，用來協調參與分布式原子事務的所有進程，確定是否提交或者終止（回滾）這個事務。

在二階段提交過程中，一個分布式事務首先使用PREPARE TRANSACTION，為二階段提交準備當前事務。如果由于任何原因PREPARE TRANSACTION 命令失敗，會變成ROLLBACK，而當前事務則會被取消。

然后我們使用COMMIT PREPARED，提交一個之前為兩階段提交預備的事務。

一旦一個事務被準備好，它會一直保持一種“游蕩”狀態直到被提交或者中止。通常情況下，事務不會在準備狀態中保持很長時間，但有時會出現錯誤所以事務必須被管理員手動移除。

我們也可以使用ROLLBACK PREPARED，取消一個之前為兩階段提交準備好的事務。

補充：postgresql vacuum操作

PostgreSQL數據庫管理工作中,定期vacuum是一個重要的工作.

vacuum的效果

1.1釋放,再利用 更新/刪除的行所占據的磁盤空間.

1.2更新POSTGRESQL查詢計劃中使用的統計數據

1.3防止因事務ID的重置而使非常老的數據丟失。

第一點的原因是PostgreSQL數據的插入,更新,刪除操作并不是真正放到數據庫空間.如果不定期釋放空間的話,由于數據太多,查詢速度會巨降.

第二點的原因是PostgreSQL在做查詢處理的時候,為了是查詢速度提高,會根據統計數據來確定執行計劃.如果不及時更新的話,查詢的效果可能不如預期.

第三點的原因是PostgreSQL中每一個事務都會產生一個事務ID,但這個數字是有上限的. 當事務ID達到最大值后,會重新從最小值開始循環.這樣如果不及時把以前的數據釋放掉的話,原來的老數據會因為事務ID的丟失而丟失掉.

雖然在新版本的Postgresql中有自動的vacuum，但是如果是大批量的數據IO可能會導致自動執行很慢，需要配合手動執行以及自己的腳本來清理數據庫。

1. vacuumdb 是 SQL 命令 VACUUM的封裝

所以用vacuumdb和vacuum來清理數據庫都可以，效果是一樣的。

2.vacuumdb 中的幾個重要參數

可以用vacuumdb –help查詢。

-a/–all vacuum所有的數據庫

-d dbname 只vacuum dbname這個數據庫

-f/–full 執行full的vacuum

-t table 只vacuum table這個數據表

-z/–analyze Calculate statistics for use by the optimizer