由 John Doe 十月 16, 2025
你知道如何运维好 PostgreSQL 的自动清理和自动分析吗？现在，PostgreSQL 有了详细的统计数据，辅助你调整相关配置。
特性提交日志
跟踪各表在 VACUUM 与 ANALYZE 操作中的累计耗时。
此提交为表的统计信息新增了四个字段，用于汇总单个表上各类操作的耗时：
- total_vacuum_time：手动执行清理（vacuum）操作的耗时
- total_autovacuum_time：自动清理守护进程（autovacuum daemon）执行清理操作的耗时
- total_analyze_time：手动执行分析（analyze）操作的耗时
- total_autoanalyze_time：自动清理守护进程执行分析操作的耗时
借助相关的“计数”字段（如vacuum_count、autovacuum_count等），用户可通过这些新增字段计算出上述各类操作的平均耗时。
讨论：https://postgr.es/m/CAA5RZ0uVOGBYmPEeGF2d1B_67tgNjKx_bKDuL+oUftuoz+=Y1g@mail.gmail.com
示例
在该特性出现前，DBA 面临三个运维的问题，而新增的字段恰好解决了这些问题：
- 操作耗时不可见：仅知道“某表执行过 10 次 autovacuum”，但不知这 10 次共占用多少 CPU/IO 资源，无法判断是否影响业务；
- 优化方向不明确：若某表查询性能差，无法区分是“analyze 执行不及时”还是“analyze 耗时过长导致未正常完成”；
- 自动运维参数难调优：autovacuum 的触发阈值（如
autovacuum_vacuum_scale_factor）仅能凭经验设置，无法基于历史耗时评估参数合理性。
例如，业务高峰期数据库 CPU 使用率突增，怀疑是手动/自动维护操作占用资源，需要快速找到耗时最长的维护任务。
要查询出手动 vacuum/analyze 耗时 Top5 的用户表，以及自动维护的耗时占比：
SELECT
schemaname || '.' || relname AS table_name,
total_vacuum_time,
total_analyze_time,
total_autovacuum_time,
total_autoanalyze_time,
-- 计算自动维护耗时占比（判断是否是自动运维导致资源占用）
ROUND(
(total_autovacuum_time + total_autoanalyze_time)::NUMERIC
/ NULLIF(total_vacuum_time + total_analyze_time + total_autovacuum_time + total_autoanalyze_time, 0)
* 100, 2
) AS ratio
FROM pg_stat_user_tables
ORDER BY (total_vacuum_time + total_analyze_time) DESC -- 按手动维护耗时排序
LIMIT 5;
快速锁定“消耗大量资源的维护操作”，若手动操作耗时过高，可调整执行时机（如避开业务高峰）；若自动操作占比高，可进一步优化 autovacuum 参数。
例如，某核心业务表（如order_info）数据更新频繁，autovacuum 频繁执行，担心影响写入性能，需评估其耗时是否合理，并调整触发频率。
可以结合“自动执行次数”计算单次平均耗时，判断是否存在异常：
SELECT
relname,
autovacuum_count,
total_autovacuum_time,
-- 计算单次自动 vacuum 平均耗时
ROUND(total_autovacuum_time::NUMERIC / NULLIF(autovacuum_count, 0), 2),
autoanalyze_count,
total_autoanalyze_time,
-- 计算单次自动 analyze 平均耗时
ROUND(total_autoanalyze_time::NUMERIC / NULLIF(autoanalyze_count, 0), 2)
FROM pg_stat_user_tables
WHERE relname = 'order_info'
ORDER BY relname;
若“单次平均耗时”远超正常范围（如超过 10 秒），可能是表数据量过大或 IO 性能不足，可拆分表或升级存储；
若“执行次数过于频繁”（如每 5 分钟 1 次），可调大autovacuum_vacuum_scale_factor（如从 0.2 改为 0.3），减少触发频率。
总结
PostgreSQL 新增的表级 vacuum/analyze 耗时统计特性，并非简单增加了几个字段，而是为 DBA 实现了从监控分析到优化运维策略的完整闭环。通过该特性，运维不用再依赖经验判断，而可以基于精准的耗时数据制定决策，无论是定位资源占用问题、优化 autovacuum 参数，还是选择维护方式，都有了明确的量化依据，最终提升数据库的稳定性与性能。
参考
提交日志：https://git.postgresql.org/pg/commitdiff/30a6ed0ce4bb18212ec38cdb537ea4b43bc99b83