当表经历大量删除、膨胀严重或需释放空间给操作系统时建议执行 FULL VACUUM；它通过重写数据页并截断文件来回收空间，但需持有 ACCESS EXCLUSIVE 锁，阻塞读写操作，适用于低峰期维护。
PostgreSQL 中的 FULL VACUUM 操作用于回收表中已删除或过期数据占用的空间，并将其真正释放回操作系统。普通 VACUUM 只能将空间标记为可重用，而 FULL VACUUM 则会重新整理数据页，使空间可以被文件系统使用。在特定场景下，执行 FULL VACUUM 是必要的。
何时需要执行 FULL VACUUM？
以下情况建议考虑执行 FULL VACUUM：
- 表中有大量删除操作后空间未被释放：当某个表经历了大批量 DELETE 操作，且后续没有足够的 INSERT 来复用这些空闲页面时，普通 VACUUM 不会把空间还给操作系统，此时 FULL VACUUM 可以压缩表并释放磁盘空间。
- 表膨胀严重（bloat）：通过查看 pgstattuple 或 pg_bloat_check 等工具发现表的实际物理大小远大于有效数据所需空间，说明存在显著膨胀，FULL VACUUM 能有效收缩。
- 无法接受表锁影响的维护窗口期间：FULL VACUUM 需要对表加 ACCESS Exclusive 锁，在此期间其他操作无法访问该表。因此通常安排在业务低峰期执行。
- 不便于使用 CLUSTER 或逻辑重建表时：CLUSTER 也能实现类似效果，但需要索引支持且更耗资源。如果不想改变数据顺序或缺乏合适索引，FULL VACUUM 是替代方案。
FULL VACUUM 的工作原理
FULL VACUUM 实际上是“原地重建”式清理：
- 扫描整个表，保留所有仍有效的元组（行）；
- 将有效数据按顺序写回到原有表文件中，跳过死亡元组；
- 截断文件末尾的空白页，从而减小实际文件大小；
- 更新 FSM（Free Space Map）和 VM（Visibility Map），优化后续插入位置选择。
与普通 VACUUM 相比，它更彻底，但代价更高。
注意事项与替代方案
FULL VACUUM 并非常规推荐操作，使用时需注意：
- 执行期间会阻塞所有对该表的读写操作，影响服务可用性；
- 需要额外磁盘空间，因为过程中可能临时占用接近原表大小的空间；
- 对于大表，执行时间较长，不适合频繁运行。
更现代的做法包括：
- 启用并合理配置 autovacuum，预防膨胀发生；
- 定期分析膨胀情况，针对性处理问题表；
- 使用 REINDEX 配合常规维护，或通过 CREATE TABLE ... AS 重建表结构来间接完成空间回收。
基本上就这些。FULL VACUUM 是一种强力但侵入性强的工具，应在确认空间浪费严重且其他方式无效时谨慎使用。日常维护依赖 autovacuum 更安全高效。
