PostgreSQL VACUUM FULL 与 pg_repack 在线表重建对比

数据库经过频繁的更新和删除操作后，表和索引会产生“膨胀”，占用比实际数据量大得多的磁盘空间，并可能降低查询性能。重建表是解决此问题的有效手段，但传统方法（如 VACUUM FULL）会锁住整张表，导致服务中断。本指南将对比两种主要重建方案：PostgreSQL 内置的 VACUUM FULL 与第三方工具 pg_repack，帮助你根据业务需求做出选择。

方案一：使用 VACUUM FULL 进行原地重建

VACUUM FULL 是 PostgreSQL 的内置命令，它通过重写整张表来回收空间。

原理与影响

VACUUM FULL 会在表上获取排他锁（Access Exclusive Lock），阻塞所有其他查询，包括读操作。它在表的当前存储位置创建一个新的、已整理的副本，然后替换旧的表文件。此过程完成后，被释放的空间可供操作系统回收。

执行步骤

1. 连接到数据库。
2. 评估膨胀情况：可使用系统视图或第三方扩展查看表的膨胀率。
3. 执行命令：对目标表运行 VACUUM FULL。

VACUUM FULL VERBOSE your_table_name;

命令选项 VERBOSE 会输出进度信息，便于监控。重建期间，对该表的所有查询都将被阻塞。

方案二：使用 pg_repack 进行在线重建

pg_repack 是一个功能强大的第三方扩展，能在不长时间阻塞写入操作的情况下重建表和索引。

安装与准备

1. 安装扩展：需要从源代码编译或通过操作系统的包管理器（如 apt、yum）安装。

   # 以基于 Debian 的系统为例
   sudo apt-get install postgresql-15-repack # 版本号需与 PostgreSQL 主版本匹配

2. 在数据库中创建扩展：使用超级用户或数据库所有者权限执行。

   CREATE EXTENSION pg_repack;

原理与优势

pg_repack 的工作原理是：

1. 在后台创建一张与原表结构相同的新表。
2. 在原表上创建一个触发器，以捕获在重建期间发生的 INSERT、UPDATE、DELETE 操作，并将这些变更应用到新表。
3. 使用 COPY 命令快速将原表数据复制到新表。
4. 复制完成后，在一个短暂的交换窗口内（通常很短，仅需获取轻量锁），原子性地交换新旧表的文件，并删除原表。
5. 整个过程中，表始终可读，写入操作仅被极短暂地阻塞。

执行步骤

1. 确认磁盘空间：pg_repack 需要大约原表大小 1.2倍 的额外磁盘空间用于存放新表。
2. 执行命令：在操作系统终端（非 psql 内）运行。

pg_repack -d your_database_name -t your_table_name --no-superuser-check

• -d：指定数据库名。
• -t：指定要重建的表名（可以多次使用 -t 来指定多张表）。
• --no-superuser-check：如果执行用户是表的所有者而非超级用户，需添加此选项。

命令会输出重建进度，完成后即告成功。

核心对比与决策指南

如何选择：一个简单的决策流程

询问自己以下问题：

1. 业务是否允许数据库表有几分钟到几小时的完全不可用时间？

   • 是：可以选择 VACUUM FULL。它简单、无需额外依赖。请务必在预先安排的维护窗口内执行。
   • 否：请直接选择 pg_repack。这是实现在线、无锁重建的唯一可靠方案。

2. 是否有足够的额外磁盘空间（约为最大要重建表的1.2倍）？

   • 是：pg_repack 是更优选择。
   • 否：如果无法获得额外空间，且能接受停机，则只能使用 VACUUM FULL。

3. 是否需要定期、自动化地处理多张膨胀表？

   • 是：pg_repack 的命令行工具和并行能力（-j 参数）使其非常适合脚本化定时任务。
   • 否：手动对单张表操作，两者皆可，但仍需基于问题1做决定。

最终建议：对于绝大多数生产环境，pg_repack 是强烈推荐的首选方案。它用少量的额外磁盘空间和一次性的安装成本，换来了无与伦比的高可用性和业务连续性保障。VACUUM FULL 更适合开发、测试环境，或作为在无法安装扩展的极端情况下的备用方案。