PostgreSQL中执行DELETE操作后，VACUUM回收空间的详细过程涉及MVCC机制、事务状态管理及存储结构的多层协作。以下是其核心步骤的深度解析：
🔍 一、DELETE操作的底层标记
- 元组状态标记
- 执行
DELETE时，PostgreSQL不会立即物理删除数据，而是将目标元组的头信息中xmax字段设置为当前事务ID，标记该元组为“逻辑删除”（即死元组）。 - 此时元组状态从
LP_NORMAL变为LP_DEAD，但仍保留在数据页中，占用物理空间。 - 关键点：此操作仅修改元组头部的几个字节，因此速度极快，但会导致表膨胀（死元组堆积）。
⚙️ 二、VACUUM的详细回收流程
阶段1：堆表扫描与死元组识别
- 可见性判断
VACUUM基于当前事务快照扫描表，检查每个元组的xmin（创建事务ID）和xmax（删除事务ID）。若xmax已提交且无活跃事务依赖此元组，则判定为可回收的死元组。 - 跳过优化
通过可见性映射（Visibility Map, VM） 跳过所有元组均活跃或已冻结的页面，减少I/O开销。 - 内存分批次处理
死元组的物理位置（TIDs）被分批存入maintenance_work_mem指定的内存区域。若内存不足，则分多次处理，每次清理一批死元组。
阶段2：索引清理
- 同步删除索引项
根据死元组的TIDs遍历所有相关索引，删除指向这些元组的索引条目。若索引页内所有条目均被删除，则尝试释放该页（B-Tree索引中标记为BTP_DELETED）。 - 性能瓶颈
索引清理常占VACUUM耗时的70%以上，尤其对多索引大表。增大maintenance_work_mem可缓存更多TIDs，减少索引扫描次数。
阶段3：堆元组清理与空间重组
- 物理空间标记
将死元组对应的行指针（Line Pointer）标记为LP_UNUSED，其原占用的空间被标记为“可重用”，并记录到空闲空间映射（Free Space Map, FSM） 中。 - 页内碎片整理
若页内存在碎片化空闲空间，VACUUM会重组剩余元组，将可用空间合并为连续区域，供后续INSERT或UPDATE重用。 - 事务冻结（Freeze）
对年龄超过vacuum_freeze_min_age的元组，将其xmin设置为FrozenXID（特殊事务ID 2），防止事务ID回绕（Wraparound）。
阶段4：末端截断与空间释放
- 文件截断条件
若表文件末尾存在连续的空页（无任何活跃元组），VACUUM会尝试移除这些空页，将空间归还操作系统。 - 锁与并发限制
截断需短暂获取排他锁（约毫秒级），若其他会话持有该表快照则截断失败。
📊 三、空间回收的类型与效果
| 回收类型 | 空间去向 | 是否减少物理文件 | 锁级别 |
|---|---|---|---|
标准VACUUM | 表内部重用（FSM管理） | ❌ 否 | 共享锁（不阻塞读） |
VACUUM FULL | 归还操作系统 | ✅ 是 | 排他锁（阻塞所有） |
- 标准
VACUUM：仅标记空间可重用，物理文件大小不变（除非末端截断成功）。 -
VACUUM FULL：创建新表文件并重写活跃数据，彻底释放空间，但需重建索引且长时间锁表。
⚠️ 四、关键影响因素与优化
- 长事务阻塞
若存在长事务（如未提交的查询），其快照可能阻止VACUUM回收与其重叠事务期的死元组，导致空间滞留。监控pg_stat_activity终止长事务可缓解。 - FSM与VM的维护
- FSM：以二进制树结构记录每页空闲空间，供插入操作快速定位可用页面。
- VM：标记全可见或全冻结页，加速后续
VACUUM与仅索引扫描。
- 性能调优参数
-
maintenance_work_mem：增大可提升索引清理效率（建议设为1–2GB）。 -
autovacuum_vacuum_scale_factor：对大表调低此值（如0.01），避免死元组堆积。
💎 总结
DELETE + VACUUM的回收本质是逻辑标记→空间重用的协作：
- DELETE 仅设
xmax，生成死元组； - VACUUM 通过事务快照判定可回收元组，清理索引并标记空间至FSM；
- 空间重用 由后续DML实现，物理文件大小通常不变（除非末端截断或
VACUUM FULL）。
运维建议：依赖autovacuum常态维护，仅在表膨胀严重时手动执行VACUUM或改用pg_repack在线重组。
