题目与背景
一套 PostgreSQL 18 集群承载高更新率订单表和低频归档表。最近出现死元组堆积、查询变慢与磁盘 I/O 峰值。请设计 autovacuum worker 容量治理，说明 autovacuum_worker_slots、autovacuum_max_workers、每表参数、并行维护和应急取舍。
面试官考察什么
- 能否区分 worker 资源上限、同时运行数量、触发阈值和单次 VACUUM 的并行度。
- 能否解释 PostgreSQL 18 新增的
autovacuum_worker_slots与运行时调整边界。 - 能否用进度视图、死元组、年龄和 I/O 指标定位瓶颈。
- 能否在防止事务 ID wraparound、业务延迟和磁盘压力之间做有序取舍。
先问清楚的澄清问题
工作负载
每个数据库和表的更新、删除、插入速率是多少？热点表是否有大量索引、长事务或批量删除？SLA 更关注查询延迟、写入吞吐还是磁盘增长？
资源边界
CPU、I/O、内存和磁盘增长上限是多少？max_worker_processes、max_parallel_workers、maintenance_work_mem 以及容器或虚拟机限制如何配置？
风险与恢复
是否接近事务 ID wraparound？能否在低峰执行手工 VACUUM 或分区切换？哪些表允许临时降低写入，哪些指标必须保留审计？
30 秒回答框架
我会先按表和数据库量化死元组增长、autovacuum 延迟、事务年龄和 I/O，再分配 worker slots 与最大并发。热点表用较低的 scale factor 和合理的 threshold，冷表保持较低调度频率。并发提高前先核对 CPU、I/O 和维护内存，使用进度视图验证是否真的缩短 backlog。任何 wraparound 风险优先级最高，业务限流和手工维护作为有界应急措施。
深入解答步骤
1. 画出资源层级
autovacuum_worker_slots 在启动时为 autovacuum worker 预留 backend slots；PostgreSQL 18 默认通常为 16，但可能受内核设置影响。autovacuum_max_workers 控制同时运行的 worker 数，不能高于 slots 的有效上限。max_worker_processes、CPU 和 I/O 仍是共享资源，不能只看一个参数。
2. 设计分层并发
先把 autovacuum_worker_slots 设为能覆盖峰值所需的资源池，再用 autovacuum_max_workers 控制常态并发。PostgreSQL 18 允许在不重启的情况下把 autovacuum_max_workers 调到 slots 上限以内，但 slots 自身只能在服务器启动时设置。扩容前预留后台进程、连接和操作系统信号量。
3. 按表设置触发阈值
全局阈值适合作为安全底线，热点表用存储参数降低 autovacuum_vacuum_scale_factor 或设置更合适的 autovacuum_vacuum_threshold。插入密集表还要评估 autovacuum_vacuum_insert_threshold。按表配置应根据死元组增长率和表大小计算，避免小表等待太久或大表频繁扫描。
4. 控制单次 VACUUM 的资源
普通 VACUUM 可与读写并行，但会产生 I/O。需要并行维护时，max_parallel_maintenance_workers 同时适用于建立索引和非 FULL 的 VACUUM，实际 worker 还受 max_worker_processes 与 max_parallel_workers 限制。maintenance_work_mem 对并行维护命令按整条命令计算，但 CPU 和 I/O 仍可能增加。
5. 处理 wraparound 与长事务
即使关闭常规 autovacuum，系统仍会为防止事务 ID wraparound 启动必要的 autovacuum。监控最老事务年龄、冻结进度和阻塞 VACUUM 的长事务；wraparound 保护不能被业务锁或普通延迟策略覆盖。必要时先终止阻塞事务、暂停低优先级批处理，再执行目标表维护。
6. 建立可操作的观测
使用 pg_stat_progress_vacuum 查看阶段、扫描块、已清理块、索引循环、死元组字节和 cost delay。结合 pg_stat_all_tables 的 ndeadtup、lastautovacuum、lastautoanalyze、表大小和事务年龄，计算 backlog 与完成时间。log_autovacuum_min_duration 用于保留慢任务证据；pg_stat_io 可区分 autovacuum worker 的 I/O 影响。
7. 滚动调参与回滚
一次只改一个维度：先提高可用 slots 或 max workers，再观察 CPU、I/O、查询延迟和 backlog；若资源争用上升，回退并发、降低单表频率或错开批量任务。每次变更记录版本、表范围、指标窗口和回滚值，避免把短时 backlog 误判为永久容量不足。
高质量示例回答
我会把 worker slots 视为资源池，把 max workers 视为常态并发，把表级 threshold 和 scale factor 视为工作生成器。热点表按死元组增长率降低触发阈值，冷表避免不必要扫描；先在当前硬件上验证 worker 对 I/O 和查询延迟的影响，再逐步提高并发。观测上同时看进度阶段、ndeadtup、事务年龄、autovacuum 日志和 pg_stat_io。wraparound 风险优先于普通延迟，长事务阻塞时先处理阻塞源，所有调参都保留可回滚记录。
常见错误
- 只把
autovacuum_max_workers调大，却没有增加 slots 或核对共享 worker 池。 - 把 slots 当成实际并发，忽略它只能在启动时配置。
- 所有表使用同一个 scale factor，导致小表过晚、大表过频。
- 用
VACUUM FULL作为日常方案，忽略锁和重写成本。 - 只看磁盘空间，不看事务年龄、死元组和进度阶段。
- 为追求延迟关闭 autovacuum，遗漏 wraparound 保护。
追问与回答
autovacuum_worker_slots 和 autovacuum_max_workers 有什么区别？
前者是启动时预留的 worker backend slots，后者是同时运行的 autovacuum 进程上限。max workers 高于 slots 不会带来对应并发；PostgreSQL 18 支持在 slots 范围内运行时调整 max workers。
并发越高，VACUUM 越快吗？
不一定。并发可能缩短单项维护时间，却增加 CPU、I/O 和业务争用。应以 backlog 完成时间、查询延迟和 I/O 峰值共同判断。
为什么要按表设置 scale factor？
比例阈值对大表会产生很大的绝对死元组数，对小表又可能过于稀疏。按表设置能让触发量匹配更新率、表大小和 SLA。
如何证明 worker 真的被 I/O 拖慢？
用 pg_stat_progress_vacuum 看阶段与 delay time，结合 pg_stat_io 的 autovacuum worker 行、磁盘延迟和业务查询指标，建立同一时间窗口的因果证据。
什么时候必须优先处理 wraparound？
当最老事务年龄逼近保护阈值、冻结进度落后或系统已经运行防 wraparound autovacuum 时，必须优先解除阻塞并完成冻结维护；普通业务优化应让位于此风险。