autovacuum_vacuum_scale_factor 是触发 autovacuum 的比例阈值，需与 autovacuum_vacuum_threshold 配合使用；单独调小易致小表频繁 vacuum 或大表仍延迟，应按表热点程度 per-table 调整并结合 analyze 保证 reltuples 准确。
autovacuum_vacuum_scale_factor 是什么，为什么不能只调小它
这个参数控制 postgresql 自动清理（autovacuum）触发的“比例阈值”：当表中被删除或更新的行数超过 autovacuum_vacuum_scale_factor × 表总行数 时，就会触发 vacuum。默认值是 0.2（即 20%），对大表来说，意味着要等 20% 的行“变脏”才清理——可能已经积压几百万死元组，IO 突增、查询变慢、bloat 严重。
但直接把它设成 0.01 甚至 0.001 是常见误区：
- 对小表（比如只有几百行）会频繁触发 vacuum，浪费资源，还可能和业务写入抢锁
- PostgreSQL 不会因为 scale_factor 小就“更勤快”——它仍受
autovacuum_naptime和后台 worker 数量限制，实际调度有延迟 - 真正起作用的是 scale_factor 和
autovacuum_vacuum_threshold的组合结果，单独调一个容易失衡
必须同时配对调整 autovacuum_vacuum_threshold
autovacuum_vacuum_threshold 是一个固定行数下限，只要表里死元组达到这个数量，不管表多小都会触发 vacuum。默认是 50。它和 autovacuum_vacuum_scale_factor 共同决定最终触发阈值：
触发条件 = dead_tuples ≥ autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor × pg_class.reltuples
所以调优本质是设置一个合理的“基础门槛 + 比例增长斜率”。例如：
- 想让 10 万行的表在 1000 行死元组时就 vacuum → 设
autovacuum_vacuum_threshold = 500，autovacuum_vacuum_scale_factor = 0.005（500 + 0.005×100000 = 1000） - 对超大表（1 亿行），scale_factor 保持 0.001，threshold 提到 5000，则触发点是 5000 + 100000 = 10.5 万死元组，比默认的 2000 万更敏感
- 注意：
pg_class.reltuples是统计估算值，不是实时精确行数，所以阈值本身就有浮动
per-table 覆盖比全局配置更安全
全局改 autovacuum_vacuum_scale_factor 影响所有表，包括系统表和冷数据表，风险高。更稳妥的做法是针对热点表单独设置：
- 用
ALTER TABLE orders SET (autovacuum_vacuum_scale_factor = 0.002) - 或同时设 threshold：
ALTER TABLE orders SET (autovacuum_vacuum_threshold = 1000) - 修改后不会立即生效，要等下次 autovacuum worker 扫描到该表（通常几秒内），且需确保
autovacuum = on - 查看当前设置：
select relname, reloptions FROM pg_class WHERE relname = 'orders'
怎么验证调得是否合理
光看参数没用，得观察实际行为：
- 查最近 vacuum 记录：
SELECT * FROM pg_stat_all_tables WHERE schemaname = 'public' AND relname = 'orders' ORDER BY last_autovacuum DESC LIMIT 1，重点关注n_dead_tup（触发前的死元组数）和last_autovacuum - 如果
n_dead_tup总卡在某个值附近（比如总是 5000～6000），说明你的 threshold + scale_factor 组合基本生效了 - 如果
last_autovacuum隔很久才更新，或者n_dead_tup动不动上十万，说明阈值还是太高，或 autovacuum worker 不够（检查autovacuum_max_workers） - 注意：vacuum 本身不释放磁盘空间给操作系统（除非执行
VACUUM FULL），所以 bloat 指标要看pgstattuple扩展里的dead_tuple_percent
最麻烦的不是算错公式，而是忘了 reltuples 会滞后于真实数据量——统计信息不及时更新时，autovacuum 会按过时的行数算阈值，导致真空延迟。定期跑 ANALYZE 或打开 autovacuum_analyze_scale_factor 才能闭环。