原因在于以下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分去清理一遍。哈哈