> 本文由 苏州市天智教育培训中心 技术团队整理，基于真实生产故障复盘，面向一线运维与开发同学，可直接用于排障参考。

一、问题现象

磁盘空间告警，查下来某张表 40GB，但实际数据只有 3GB。autovacuum 日志显示"skipping"或者长时间没有进展，典型的膨胀问题。

二、排查思路速览

先按下面的路径走，每一步都有明确的判断分支，避免"上来就重启"这种无效操作。

PostgreSQL · 表膨胀与 autovacuum 卡住磁盘告警 / 查询变慢开始查表大小与死元组比例死元组占比是否很高？判断是膨胀：autovacuum 未生效或被阻塞否看是否有长事务 / 复制槽拖住查长事务与空闲事务查复制槽是否活跃手动 VACUUM (FULL) 或 pg_repack 回收调整 autovacuum 参数避免复发表体积回落，查询恢复结束

三、先看清链路：PostgreSQL 的典型架构

动手之前先明确"请求经过了哪些环节"，把问题定位到具体一层，排查效率会成倍提升。

PostgreSQL 运行要点连接PgBouncer连接池最大连接数存储shared_buffersWALWAL 归档维护autovacuum统计信息膨胀回收高可用流复制Patroni备份 PITR

四、根因分析

结合现场日志、监控与配置，逐条核对，绝大多数情况都能收敛到下面这几类原因：

  1. 长事务 / 未提交事务阻止 vacuum 清理死元组
  2. 未使用的复制槽导致 WAL 与死元组无法回收
  3. autovacuum 参数过于保守，大表来不及回收
  4. 批量删除后没有及时 VACUUM

五、处置过程

处置原则：先止血、再根治。先让业务恢复，再回头解决根因，不要在故障中做长期改造。

  1. 长事务与复制槽是 PG 膨胀的两大隐形杀手
  2. 大表回收优先用 pg_repack（不锁表），VACUUM FULL 会锁
  3. autovacuum 参数按表大小分级设置
  4. 监控死元组比例与表膨胀率

六、关键命令与配置

下面这些命令/配置可以直接在生产上核对（执行前请确认环境与权限）：

-- 表膨胀情况
SELECT relname, n_live_tup, n_dead_tup,
       ROUND(n_dead_tup*100.0/NULLIF(n_live_tup+n_dead_tup,0),1) dead_pct,
       pg_size_pretty(pg_total_relation_size(relid)) total
FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 10;

-- 长事务
SELECT pid, now()-xact_start dur, state, left(query,80)
FROM pg_stat_activity WHERE xact_start IS NOT NULL
ORDER BY dur DESC LIMIT 5;

-- 复制槽
SELECT slot_name, active, restart_lsn FROM pg_replication_slots;

七、复盘

故障恢复后必须做复盘，重点不是"谁的责任"，而是"哪个机制缺位"：

  1. 根因是一个"忘了提交"的事务挂了两天，vacuum 一直无法推进
  2. 复盘发现没有长事务监控，这类问题会反复发生
  3. 批量删除任务跑完没做 VACUUM，一次性制造了 30GB 垃圾

八、预防建议

  1. 监控长事务（超过 5 分钟即告警）与空闲事务
  2. 复制槽定期审计，不用的立刻删除
  3. 批量删除后跟一次 VACUUM
  4. 大表用 pg_repack 做在线回收

九、官方版本动态（自动同步）

以下内容由官方发布渠道自动同步（最近同步 2026-10-11），用于提醒你：同一个问题在不同版本上的表现与处置方式可能不同，动手前先确认线上实际版本。

  • PostgreSQL 官方新闻 42.7.14（2026-10-09 发布）：2026-10-07: PostgreSQL JDBC 42.7.14 Security update for mult 官方说明
  • PostgreSQL 官方新闻 1.0（2026-10-07 发布）：pgx-bm25 1.0: BM25 ranked full-text search as a native Postg 官方说明
  • PostgreSQL 官方新闻 1.0.0（2026-10-07 发布）：pg_plan_filter 1.0.0 released 官方说明

> 版本升级前务必先在测试环境验证，特别是标注了「破坏性变更」或「停止维护」的版本。

十、写在最后

上面这套排查方法，是 PostgreSQL 在生产环境中最常见的一类问题，也是大数据方向岗位面试里经常被追问的场景题。很多人搜「苏州运维」或者关心「数据库运维培训」，真正想确认的其实是：课程讲不讲真实的线上故障。我们在云计算运维工程师课程里，会把这类故障做成实战演练——从监控曲线、日志、命令输出一路推到根因，再动手恢复，而不是背命令。苏州校区面授 + 线上同步，主打苏州运维方向的实战教学，就业推荐覆盖江浙沪。如果你正在做大数据方向、或者想转行进入大数据领域，可以了解一下我们的课程（苏州运维、数据库运维培训、苏州运维哪个好），也可以直接联系我们做一次免费的职业与技术评估。

十一、延伸阅读