PostgreSQL 19 autovacuum有什么变化？并行清理和表评分说明

佚名 2026-11-02 11:40:01

大表维护占用很久、其他表又排着队，说明维护速度或调度可能跟不上数据增长。19既增加部分索引处理的并行能力，也用评分决定哪些表更需要优先维护。

一个改进负责怎样分担单次任务，另一个负责怎样排先后。它们不会让所有维护步骤自动并行，更无法替满负荷的磁盘增加实际速度。

一、autovacuum 平时到底在忙什么？

记录被更新或删除后，旧版本要等不再被事务使用，才能清理并重复利用空间。autovacuum会自动安排这些清理工作，也负责相关统计信息更新。

它还承担事务 ID 等维护工作。即使一张表平时不怎么改动，也不能因此永远不清理。不要为了避免后台 I/O，长期关闭它。

19 的并行 autovacuum，重点是索引 vacuum 和索引 cleanup 阶段。可以理解成：一个负责这张表的维护进程，再请额外的工作进程分担符合条件的索引任务。

它与“同时维护多张表”的 autovacuum_max_workers 不是同一个开关。前者关心一张表的索引任务能否多人分担，后者关心能有多少个普通 autovacuum 进程同时工作。

并行效果还取决于索引数量、大小和类型。如果主要耗时在表扫描，或者只有一个适合处理的索引，增加并行工作进程也未必有明显收益。

新增参数 autovacuum_max_parallel_workers 默认是 0，也就是默认不启用这一并行能力。先查当前配置：

SHOW autovacuum_max_workers;SHOW autovacuum_max_parallel_workers;SHOW max_parallel_workers;SHOW max_worker_processes;

这里不仅有单个 autovacuum 的限制，还有实例可用工作进程的总量。查询、维护等任务可能争用资源，填了某个数字，不代表每次都能分到那么多进程。

不要把“CPU 有 16 核”直接换算成“并行数设 16”。先选一张有多个大索引、维护确实很慢的表测试，观察清理时长和业务延迟，再逐步扩大。

以前的表处理顺序不够贴近实际紧迫程度。19 会综合几个方向看一张表：事务 ID 有多老、旧行积累到了什么程度、插入是否达到维护要求，以及统计信息是否需要更新。

每个方向都有一项分数，表的优先级取其中最高的一项，而不是简单地把所有数字加起来。这样，某一项已经很紧迫的表，就更容易被优先处理。

选择数据库和选择库内的表，仍然是两个步骤；评分系统主要用于库内的表排序。它也不会因为某张表分高，就马上打断所有正在运行的工作。

SELECT * FROM pg_stat_autovacuum_scores;SELECT * FROM pg_stat_progress_vacuum;

两个视图分别用于查看表评分与正在执行的清理。监控程序应按19的字段结构适配，不能直接假设它们与旧版本相同。

先积累一段时间的日志，再判断是触发太少、执行太久，还是经常被其他操作打断。原因弄清后再调整对应参数。