PostgreSQL中 Vacuum 略谈

VACUUM doc

路由清理

PostgreSQL 需要定期维护清理,一般都是由守护进程自动清理的,我们只是需要参数调优,也
可以执行脚本定时去清理回收。

Vacuumming Basics

PG不得不对每张表进行 Vacuum 命令,原因如下:

1、为了回收和再利用通过更新或者删除行所占用的磁盘空间

2、为了更新被PG查询计划所使用的数据分析

3、为了更新只读索引扫描的可见的集合

4、避免由于事务ID或者混合事务ID丢失历史数据

  • 由于这些原因,在进行频繁的 VACUUM 操作时进行规定:

  • 标准 VACUUM

    进行回收时,生产环境不影响数据库库的正常使用(SELECT、INSERT、UPDATE、DELETE),
    并行使用,清理时不允许对表结构进行修改(ALTER TABLE)推荐使用该方案

  • VACUUM FULL

    a、可以回收大量空间,但是比标准回收执行慢
    b、运行时需要锁表

VACUUM 运行会导致读写性能比较差,所以需要调整一些参数降低影响

temp_file_limit = -1 #默认-1表示不限制每个进程可使用的最大临时文件限制,单位kb
#max_files_per_process = 1000 #每个子进程允许同时打开文件的最大数量

在执行 VACUUMANYLYZE 期间,系统会维护一个用于估算各种I/O操作所消耗的内部
计数器,当该值达到vacuum_cost_limit的值时,该进程会休眠 vacuum_cost_delay
定的时间,并重置计数器的值,继续运行 VACUM 或者 ANYLYZE 操作

vacuum_cost_limit = 200  
vacuum_cost_delay = 0  # 单位微秒,默认为 0 没有开启

该参数 vacuum_cost_delay 主要用于并发时降低I/O的影响,推荐为10

vacuum_cost_page_hit = 1 # 代表从缓存池查找共享的hash table并扫描 该`页`的内容
                         #的估计值
vacuum_cost_page_miss = 10      # 0-10000 credits
vacuum_cost_page_dirty = 20

NOTE

当一张表中包含了大量数据时,同时进行删除或者更新操作时,VACUUM 并不是最好的方案,
如果有该情况,则应该使用 VACUU FULL ,当执行 ALTER TABLE 时,会重新 COPY
个表和重新构建索引,会进行执行锁,临时占用和原始表大小的磁盘空间,直到新数据COPY完
成。

升级执行计划

执行计划通过自己或者 VACUUM调用命令 ANALYZE 收集统计,

创建 表达式索引 能够提高查询执行计划

default_statistics_target = 100  #提高查询的 析计划

猜你喜欢

转载自blog.csdn.net/yaoqiancuo3276/article/details/80376540