原因在於以下3點:
-
釋放,再利用 更新/刪除的行所占據的磁盤空間.
-
更新PostgreSQL查詢計划中使用的統計數據.
-
防止因事務ID的重置而使非常老的數據丟失.
第一點的原因是PostgreSQL數據的插入,更新,刪除操作並不是真正放到數據庫空間.如果不定期釋放空間的話,由於數據太多,查詢速度會巨降.
第二點的原因是PostgreSQL在做查詢處理的時候,為了是查詢速度提高,會根據統計數據來確定執行計划.如果不及時更新的話,查詢的效果可能不如預期.
第三點的原因是PostgreSQL中每一個事務都會產生一個事務ID,但這個數字是有上限的. 當事務ID達到最大值后,會重新從最小值開始循環.這樣如果不及時把以前的數據釋放掉的話,原來的老數據會因為事務ID的丟失而丟失掉.
話說回來vacuum操作可以手動和自動.如果有專門的數據庫維護人員的話,可以適時進行.但很多系統為了節省維護成本,這樣就需要依賴自動vacuum了.
雖說定期vacuum是PostgreSQL的一個弱點,不過在8.3版本以后,把這個任務交給自動vacuum就可以了.
要使自動vacuum有效,必須設置track_counts參數為true.具體的設置可以參照官方的文檔.
定期vacuum還是自己寫一個shell來自動執行比較好.
黃海在WINDOWS下執行的語句:
vacuumdb -U postgres -d lxyy_db --analyze
crontab中設置執行這個shell的用戶為數據庫超級用戶,然在在這個超級用戶的home下面建一個.pgpass認證文件,就可以定期執行batch了.
1, vacuumdb綜述 vacuumdb是清除PostgreSQL數據庫的工具。其實vaccumdb是SQL命令VACUUM的外部包裝。
2. vacuumdb的幾個有用參數
-a/--all vacuum所有的數據庫
-d dbname 只vacuum dbname這個數據庫
-f/--full 執行full的vacuum
-t table 只vacuum table這個數據表
-z/--analyze Calculate statistics for use by the optimizer
3. 實際的維護
vacuumdb -d yourdbname -f -z -v 效果還是很明顯的,其中有一張表從原來的3G多一下子變到了600M。 最主要很久沒去垃圾清理了,所以我們有必要每天去清理一遍:在crontab里面添加:
02 2 * * * postgres vacuumdb -d digibot -f -z -v >> /tmp/vacuumdb.log
每天凌晨2點02分去清理一遍。哈哈