前言

最近在生产环境中碰到 6000 条数据在没有索引的查询下耗时 9 秒 的尴尬局面。业务方迫切需要在秒级返回结果，而我们却只能看到硬盘空间从 16 MB 暴涨到 1.8 GB全表扫描几乎把程序卡死。

问题根源回顾》）

PostgreSQL 的 MVCC 机制在每次 UPDATE/DELETE 时不会立刻物理删除旧行，而是留下死元组并打上“可重用”标记。这些标记本身并不回收空间，只有在后续插入/更新时才能真正复用。

上一次分析发现：

• 死元组比例约为 20%说明自动清理任务正常运行。按理说，
• 可重用空间未被利用导致文件体积继续增长。

为什么 16 MB 数据会膨胀到 0.8 GB？

M V C C 会产生垃圾空间，但 PostgreSQL 本身会把这些空间标记为可重用。我们的表却没有把这些标记转化为真实的复用，从而出现了巨大的磁盘浪费。

DeepSeek 对空间重用的解释

"小于 8 KB 的行能更好地利用历史版本留下的碎片；不过，行太大则很难复用 free space"

空间重用的两种主要方式

普通插入 / 更新：基于 FSM 的跨页面重用

• 流程： INSERT → 查询 FSM → 找到首个足够空闲的页面 → 写入 → 如页面满则更新 FSM 条目。
• 效果：新行填进已删除行留下的空洞，无需 文件。
• 限制：对大于 8 KB 的行无效。需要使用 TOAST 存储，此时 FSM 针对的是 TOAST 表。

HOT 更新：同一页面内就地重用

满足以下条件时触发 HOT 更新：

• 索引列未改变。
• 新版本可以放入旧行所在页面的空闲区域。

实现过程：

• 将旧行标记为“死”。老实说，
• 新行指针指向旧行。实现元组链，
• 不产生新页面、不更新索引。性能极佳，页面内部空间高效复用。

说到你的场景，为何空间复用失效？

表中平均每行约 282 KB 远超单页 大小。从结果如下来看，

1. 每行跨越约 282KB / 8KB ≈ 36 个连续页面。
2. 任何字段的微小更新都无法进行 HOT。因为同页没有足够连续空间容纳完整的新版本，只能在新位置分配另一整块 36 页。旧版所在的 36 页变成死元组。
3. FSM 只能记录每页剩余字节数，对跨页的大块碎片毫无帮助——碎片不足以拼凑出另一个 282 KB 的连续块。
4. 于是每次更新都导致表文件额外增长约 36 × 8KB = 288KB 。几十次更新后文件体积从几 MB 瞬间飙至百 MB、甚至 GB 级。即使 VACUUM 正常运行，也只能标记这些碎片而无法真正复用。

空间复用效率的实战方案

减小单行大小

• 将大字段拆分到子表。让主表每行保持在 <8KB 范围内。
• 这样即使只更新小字段，也能触发 HOT 更新，实现高效复用。

主动整理碎片

• VACUUM FULL 重新写入整个表，消除所有碎片。
• pg_repack 在线重建，不阻塞业务。

🚀 实验：大字段导致的空间无法复用问题验证

对 A 表进行不同规模、不同方式的更新，对比有无大字段时表空间变化。

至于实验一，批量更新 1000 次

• 结果：全表从 64KB 膨胀至约 3008KB 。

public void testA{ List types = typeService.list;for，i++) { typeService.updateBatchById;}}

再看实验二，单条慢速更新 1000 次

• 结果：全表从 64KB 膨胀至约 768KB 。

public void testA throws InterruptedException { List types = typeService.list;for，i++) { log.info;for { Thread.sleep;// 模拟慢速操作 typeService.updateById;} }}

再看实验三，加入大字段后批量/单条更新对比

• 单条慢速更新： 全表从 64KB />/448KB。其实，
• 批量快速更新： 全表从 /64KB>/>/≈15GB！严重膨胀，

测试 当表中存在大字段且采用批量更新时碎片无法被 FSM 有效利用，导致磁盘占用指数级增长。

与行动教程

• 控制单条记录大小是根本解决之道。 特别是包含大量文本、JSON 或 BLOB 字段的宽表，需要拆分或使用外部存储。
• 批量更新前务必评估影响。 如果必须批量写入。请配合离线压缩工具 ) 或分批次执行，以免一次性触发巨额膨胀。怎么说呢，
• 监控是预防利器。 定期检查 pg_stat_user_tables 中的 bloat_ratio、dead_tuple_cnt、free_space_pct 等指标。并设置告警阈值，一旦出现异常立即触发手动 VACUUM 或 REPACK。
• 运维建议：
  1. — 离线窗口执行，可彻底消除膨胀；
  2. — 在线在线压缩，无需停机；
  3. — 让超长列更好地拆块存储；