Postgres 9.5 TOAST表无限膨胀问题排查及解决方案咨询
先结合你的场景拆解核心问题：PostgreSQL 9.5中，存储大体积jsonb的sourceTable关联的TOAST表疯狂膨胀（手动清理前75GB，清理后仅416MB），但自动VACUUM完全没起作用。下面分析原因并给出落地解决方案：
一、自动VACUUM失效的核心原因
1. TOAST表的清理完全依赖主表的VACUUM触发
PostgreSQL的TOAST表不会单独触发自动VACUUM——它的清理逻辑是和主表绑定的：只有当主表满足自动VACUUM的触发条件时，才会连带清理关联的TOAST表。
从你提供的pg_stat_all_tables数据看，TOAST表的死元组（n_dead_tup=8769021）已经接近活元组数量，但主表可能还没达到自动VACUUM的触发阈值。默认的自动VACUUM触发逻辑是：
死元组数量 > autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor * 主表活元组数量
你只查询了autovacuum_analyze_scale_factor，但默认的autovacuum_vacuum_scale_factor是0.2、autovacuum_vacuum_threshold是50。如果主表活元组基数大，死元组需要积累到非常高的数量才会触发自动VACUUM，这就导致TOAST表的死元组先疯狂堆积。
2. 长事务/未提交事务锁住了死元组
从手动VACUUM的输出能明确看到：
DETAIL: 5295 dead row versions cannot be removed yet.
这说明存在长事务或未提交事务持有了旧的数据快照，PostgreSQL为了保证事务一致性，不会清理被快照引用的死元组。自动VACUUM遇到这种情况也无法回收，时间一长就会导致TOAST表体积爆炸。
3. PostgreSQL 9.5的TOAST清理局限性
9.5是2016年发布的老版本，后续版本（比如10+）对TOAST表的自动清理逻辑做了大量优化，包括更精准的触发时机、更高效的死元组识别。老版本在高频插入/删除的场景下，很容易出现清理不及时的问题。
二、彻底解决TOAST表膨胀的具体措施
1. 针对主表优化自动VACUUM触发阈值
让主表更容易触发自动VACUUM，从而连带清理TOAST表。推荐给sourceTable单独设置更激进的参数（避免影响全局其他表）：
-- 降低触发阈值，让自动VACUUM更敏感 ALTER TABLE sourceTable SET ( autovacuum_vacuum_threshold = 1000, autovacuum_vacuum_scale_factor = 0.05 );
这样只要主表死元组超过1000 + 5%的活元组数量，就会触发自动VACUUM，及时清理TOAST表的死元组。
2. 排查并处理长事务
找出持有旧快照的长事务并终止，释放死元组的清理权限：
-- 查询运行超过5分钟的活跃事务 SELECT pid, now() - query_start AS duration, query FROM pg_stat_activity WHERE state = 'active' AND now() - query_start > INTERVAL '5 minutes'; -- 终止不需要的长事务（替换成实际的pid） SELECT pg_terminate_backend(1234);
如果业务中有持续运行的只读事务（比如ETL、报表），建议调整事务的快照隔离级别，或者缩短事务运行时间。
3. 定期手动VACUUM作为补充（临时方案）
如果自动VACUUM暂时无法完全覆盖，可以用定时任务（比如Linux cron）定期执行手动清理：
# 每天凌晨2点执行VACUUM（低峰期执行更稳妥） 0 2 * * * psql -d segmentation -c "VACUUM VERBOSE ss_admin.client_attributes;"
注意：普通VACUUM不会锁表，无需担心影响业务。
4. 升级PostgreSQL版本（长期根治）
如果业务允许，建议升级到12+版本（目前稳定的LTS版本）。新版本对TOAST表的清理、自动VACUUM的逻辑都有大幅优化，能从根源上减少这类膨胀问题的发生。
5. 优化jsonb字段的使用方式
如果jsonb字段的更新频率极高，且每次更新都是全量替换，可以考虑拆分字段：把频繁更新的部分单独存成普通列，减少TOAST表的写入压力——毕竟TOAST表的每次更新都会生成新的大对象，死元组积累速度会远快于普通列。
内容的提问来源于stack exchange，提问作者Natalia
