怎么防止postgres数据膨胀

复制与德哥的博客地址为：http://blog.163.com/digoal@126/blog/static/1638770402015329115636287/

 

1. 必定要开启autovacuum。

2. 提升系统的IO能力，越高越好。

3. 调整触发阈值，让触发阈值和记录数匹配。调小autovacuum_vacuum_scale_factor和autovacuum_analyze_scale_factor。好比我想在有1万条垃圾记录后就触发垃圾回收，那么对于一个1000万的表来讲，我应该把 autovacuum_vacuum_scale_factor调到千分之一即0.001，而 autovacuum_analyze_scale_factor应该调到0.0005。

4. 增长autovacuum_max_workers，同时增长autovacuum_work_mem，同时增长系统内存。

例如对于有大量表须要频繁更新的数据库集群，能够将 autovacuum_max_workers调整为与CPU核数一致，并将 autovacuum_work_mem调整为2GB，同时须要确保系统预留的内存大于 autovacuum_max_workers* autovacuum_work_mem。

5. 应用程序设计时，尽可能避免持有事务Exclusive锁的长事务（DDL,DML都会持有 事务Exclusive锁 ）

6. 对于IO没有问题的系统，关闭autovacuum_vacuum_cost_delay。

7. 调整autovacuum_naptime参数到最低，若是仍是唤醒时间太长，能够调整代码中的限制，例如改成1毫秒：

#define MIN_AUTOVAC_SLEEPTIME 1.0               /* milliseconds */

8. 应用程序设计时，避免使用大批量的更新，删除操做，能够切分为多个事务进行。

9. 使用大的数据块，对于现代的硬件水平，32KB是比较好的选择，fillfactor实际上不须要太关注，100就能够了，调低它其实没有必要，由于数据库老是有垃圾，也就是说每一个块在被更新后实际上都不多是满的。

10. 万一真的膨胀了，能够经过table rewrite来回收(如vacuum full, cluster)，可是须要迟排他锁。建议使用pg_reorg或者pg_repack来回收，实际上用到了交换 filenode能够缩短须要持有排他锁的时间。