PostgreSQL 慢查询治理：autovacuum 滞后导致表膨胀排查与优化

最近在维护一套基于 PostgreSQL 14 的消息流水系统时，发现一张千万级表的简单索引查询耗时从原来的 5ms 劣化到了 400ms 以上。

一、问题排查：死元组（Dead Tuples）率过高

PostgreSQL 采用多版本并发控制（MVCC）机制，每次 UPDATE 实际上是在页面中插入一条新行（tuple），并将旧行标记为 Dead。如果自动清理进程（autovacuum）没有及时回收这些死元组，就会导致严重的表膨胀和索引膨胀。

查询当前表的死元组数量与健康状态：

SELECT relname, n_live_tup, n_dead_tup,
       round(n_dead_tup * 100.0 / nullif(n_live_tup + n_dead_tup, 0), 2) as dead_ratio,
       last_vacuum, last_autovacuum
FROM pg_stat_user_tables
WHERE relname = 't_message_flow';

查询结果显示：活跃行数（n_live_tup）为 800 万，而死元组（n_dead_tup）竟高达 1200 万，死元组比例超过 60%！

二、紧急治理与平滑回收

使用不锁表的 VACUUM ANALYZE 释放死元组并更新统计信息：

VACUUM (VERBOSE, ANALYZE) t_message_flow;

如果表空间极度膨胀且需要物理归还磁盘空间，可以使用官方推荐的 pg_repack 扩展在线无锁重构表结构。

三、调优 autovacuum 策略

对于高频更新的热点大表，默认的全局触发阈值太宽松，建议单独针对该表设置更激进的清理策略：

ALTER TABLE t_message_flow SET (
    autovacuum_vacuum_scale_factor = 0.05, -- 触发阈值从默认20%降低到5%
    autovacuum_vacuum_cost_limit = 2000,
    autovacuum_vacuum_cost_delay = 2
);

调整后系统死元组始终维持在 3% 以下，查询响应恢复稳定。