在PostgreSQL运维中，VACUUM是维持表健康和避免事务ID回卷的核心操作。当对一张体量较大的表执行VACUUM时，管理员往往关心任务执行到哪一步、还要多久才能结束。系统视图pg_stat_progress_vacuum正是为此设计的监控手段，它实时记录每一个正在运行的VACUUM命令的推进状态。
pg_stat_progress_vacuum视图结构
pg_stat_progress_vacuum是PostgreSQL内置的进度报告视图之一，属于pg_stat_progress系列。它的每一行对应一个当前正在执行的VACUUM（不包括VACUUM FULL以外的某些变体），无论手动执行还是autovacuum触发都会在此体现。通过联结pg_stat_activity，可以定位到具体的后台进程与执行语句。
该视图主要字段包括pid、datname、relid、phase、heap_blks_total、heap_blks_scanned、heap_blks_vacuumed、index_vacuum_count、max_dead_tuples、dead_tuples等。其中phase表示当前所处阶段，如initializing、scanning heap、vacuuming indexes、vacuuming heap、cleaning up indexes、finalizing cleanup。每个阶段的工作重心不同，扫描与索引清理往往最耗时间。
关键字段说明
heap_blks_total代表表总堆块数，heap_blks_scanned是已扫描的块数，二者之比可粗略算出堆扫描进度。heap_blks_vacuumed则是真正被清理的块数，由于可见性映射（VM）文件的存在，部分块可跳过扫描，因此scanned与vacuumed不一定相等。dead_tuples显示已收集的死元组数量，max_dead_tuples是内存中死元组数组上限，达到上限会触发一轮索引清理。
以下查询可查看当前所有库的真空进度概况：
SELECT
p.pid,
d.datname,
c.relname,
p.phase,
p.heap_blks_total,
p.heap_blks_scanned,
p.heap_blks_vacuumed,
p.dead_tuples,
p.max_dead_tuples
FROM pg_stat_progress_vacuum p
JOIN pg_database d ON p.datid = d.oid
JOIN pg_class c ON p.relid = c.oid
ORDER BY d.datname, c.relname;
各阶段工作内容与耗时特征
在scanning heap阶段，PostgreSQL顺序读取堆页并标记死元组，同时根据VM跳过全可见块以提速。如果表上长事务很多，某些死元组无法被回收，会导致dead_tuples增长但清理受限。进入vacuuming indexes阶段后，系统会对每个索引执行一次清理，此时I/O与CPU开销明显，index_vacuum_count随之增加。
vacuuming heap阶段将死元组占用的空间标记为可重用，但不一定收缩文件大小。最后的cleaning up indexes与finalizing cleanup负责清理临时结构与统计更新。若发现某个阶段停留过久，比如scanning heap中heap_blks_scanned长时间不变，通常意味着有锁等待或磁盘性能瓶颈。
结合pid诊断阻塞
当进度异常缓慢时，可通过pid关联pg_locks与pg_stat_activity排查阻塞源。例如某张表被业务长事务持有AccessShareLock，VACUUM虽能扫描但无法截断尾部空页。此时应评估事务长度或调度低峰期执行。
SELECT
a.pid,
a.query,
a.state,
l.locktype,
l.mode
FROM pg_stat_activity a
JOIN pg_locks l ON a.pid = l.pid
WHERE l.relation = '<表oid>'::regclass
AND a.pid != pg_backend_pid();
实践中的监控脚本
对于需要周期性巡检的场景，可以封装一个函数计算预估剩余比例。虽然视图本身不提供时间预估，但借助两次采样间隔的块增量，能算出平均速率并外推。注意这种推算在相位切换时会失真，仅作参考。
下面示例展示如何每五秒采样一次并输出简单报告：
-- 第一次采样
CREATE TEMP TABLE snap1 AS
SELECT relid, heap_blks_total, heap_blks_scanned, now() AS ts
FROM pg_stat_progress_vacuum;
-- 等待一段时间后第二次采样
SELECT pg_sleep(5);
SELECT
c.relname,
s2.heap_blks_scanned - s1.heap_blks_scanned AS scanned_delta,
(s2.heap_blks_scanned - s1.heap_blks_scanned)::float
/ EXTRACT(EPOCH FROM (s2.ts - s1.ts)) AS blocks_per_sec
FROM snap1 s1
JOIN pg_stat_progress_vacuum s2 ON s1.relid = s2.relid
JOIN pg_class c ON s2.relid = c.oid;
常见误区与注意事项
不少用户误以为pg_stat_progress_vacuum能监控VACUUM FULL的进度，实际上VACUUM FULL使用簇操作，其进度记录在pg_stat_progress_cluster视图中。另外，autovacuum工作进程也会出现在本视图，若频繁看到同一张表反复处于vacuuming indexes，说明表膨胀严重或autovacuum参数过于保守。
还应避免仅依靠dead_tuples绝对值判断健康度，因为max_dead_tuples受maintenance_work_mem限制。适当调大该参数可减少索引清理轮次，从而降低phase切换开销，这在宽表多索引场景下效果明显。
合理使用pg_stat_progress_vacuum，可以让数据库维护从黑盒等待变为透明调控，是PostgreSQL性能治理的基本功。
pg_stat_progress_vacuumPostgreSQLVACUUM修改时间：2026-08-12 03:18:30