PostgreSQL表行数增加但大小骤降，是否正常？求排查建议

核心结论 #

这种备份文件持续下降但对应表行数反而增加的现象不属于正常情况。正常逻辑下行数增长通常会伴随数据量（备份大小）的上升或稳定，除非有特定的存储/数据变更导致压缩率大幅提升，而这种突变需要深入排查。

排查思路与建议 #

1. 检查异常表的存储与压缩配置

针对表1、3、4、7、12，执行以下查询查看存储参数：

SELECT relname, reloptions FROM pg_class WHERE relname IN ('表1','表3','表4','表7','表12');

重点确认：

• 是否启用了TOAST压缩、第三方压缩插件（如pg_zstd），且2月2日后是否调整过压缩级别/策略
• 表的fillfactor参数是否有变更（该参数影响数据填充密度，不过通常不会导致这种幅度的备份大小变化）

2. 分析表的行大小变化

计算异常表的平均行大小，对比不同备份恢复后的数值：

SELECT relname, 
       ROUND((pg_total_relation_size(relid)/reltuples)::numeric, 2) AS avg_row_size_bytes
FROM pg_stat_user_tables 
WHERE relname IN ('表1','表3','表4','表7','表12');

如果平均行大小大幅下降，说明：

• 可能存在批量更新操作，将大字段（TEXT、BYTEA等）替换为短内容
• 客户可能执行了数据归档，将大体积历史数据迁移至外部存储，仅保留轻量引用

3. 核查PostgreSQL后台与配置变动

• 检查自动VACUUM行为：查看pg_stat_user_tables中的n_dead_tup（死元组数量）、last_autovacuum（最后自动VACUUM时间），确认是否触发了VACUUM FULL（该操作会整理表空间、消除碎片，但通常不会在行数增长时让备份变小）
• 确认pg_dump工具版本是否有变更：即使PostgreSQL主版本未更新，pg_dump单独升级也可能影响压缩效率（执行pg_dump --version对比不同时间点的版本）

4. 排查客户侧操作

• 与客户确认是否有自定义脚本、ETL工具在操作这些表，比如数据脱敏、批量压缩大字段、历史数据清理等
• 检查数据库日志（若开启log_statement = 'all'或类似级别），查看2月2日后是否有针对异常表的批量UPDATE/INSERT/DELETE操作

5. 验证备份过程的完整性

• 查看备份脚本的执行日志，确认pg_dump是否有未被捕获的警告/错误（比如部分数据未被成功备份）
• 检查备份存储目录所在的文件系统，是否在2月2日后开启了透明压缩（如ZFS、ext4的压缩功能），这会直接影响备份文件的显示大小

内容的提问来源于stack exchange，提问作者HezelTm