如何用PostgreSQL的pg_repack在线重建表消除膨胀而不锁表

在PostgreSQL长期运行的环境中，频繁更新和删除会导致表与索引产生大量死元组，即所谓的表膨胀。常规VACUUM只能标记空间复用，无法缩小物理文件；VACUUM FULL又会全程持有排他锁，使业务完全停写。pg_repack作为一款开源扩展，能够在几乎不阻塞正常读写的前提下，重建表结构并压缩空间，是运维中处理膨胀的重要工具。

pg_repack的工作原理与核心流程

pg_repack的基本思路是“影子表替换”。它首先在数据库中创建一个结构相同的新表，将旧表数据批量拷贝过去；与此同时，通过触发器或逻辑解码记录原表上的增量变更。待全量数据同步完成，工具会追平这段时间产生的日志，然后在极短时间内对原表加锁，把新表重命名为原表名，并删除旧表。整个过程里，长时间的操作用的是共享锁或自主表锁，不会阻碍其他会话的增删改查。

具体实现上，pg_repack会在目标库里建立名为repack的辅助模式，其中包含日志表与触发器等对象。对于带有主键或唯一索引的表，它利用主键定位行变更；对于无唯一约束的表，则需借助ctid配合行级触发器捕获所有变动。日志追平阶段会循环读取日志表，将插入、更新、删除操作重放到新表，保证最终数据一致性。正因如此，表上必须存在可用作重放依据的约束，否则工具会拒绝执行。

与VACUUM FULL相比，pg_repack不会在拷贝之初就锁死全表，而是把排他锁压缩到表名切换的一刻，通常只持续毫秒级。对于几十GB甚至上TB的表，这种差异决定了业务能否持续对外服务。同时，pg_repack还能顺带完成CLUSTER类似的物理排序，使数据按索引顺序存放，进一步优化范围扫描性能。

安装部署与基础使用方式

使用pg_repack前，需要在数据库服务端安装扩展包，并在客户端机器准备可执行命令。以常见Linux发行版为例，可通过包管理器安装postgresql-版本号-repack，随后用超级用户连入目标库执行CREATE EXTENSION repack。这一步会在库中生成repack模式及函数，供后续调用。若缺少该扩展，客户端运行时会报错提示无法连接辅助对象。

基础命令形式非常简单，例如对单个表重建可执行：pg_repack -t 表名 -d 数据库名 -h 主机 -U 用户。工具会先校验表是否满足前提，然后输出各阶段进度。若要对全库所有可处理表批量整理，可省略-t直接指定数据库。实际运行中建议搭配--jobs参数并行处理多个索引，缩短大表维护时长，但并行度过高会加剧IO与WAL写入压力，需要结合机器配置权衡。

下面是一段在Ubuntu系统安装并创建扩展的示例脚本，展示从操作系统包到数据库对象的完整准备动作：

-- 操作系统层安装（示例为PostgreSQL 14）
-- sudo apt-get install postgresql-14-repack

-- 数据库内创建扩展
CREATE EXTENSION IF NOT EXISTS repack;

-- 查看辅助模式是否生成
dn repack

值得注意的是，pg_repack在执行期间会占用额外磁盘空间，因为新旧表短暂共存。若原表已非常庞大且剩余空间不足，可能导致重写失败。因此在计划任务前，运维人员应确保空闲容量至少等于原表加索引大小，并尽量避开业务高峰，减少日志表堆积。

性能影响与常见避坑要点

尽管pg_repack以在线为卖点，但它并非零成本。全量拷贝阶段会产生大量顺序读与顺序写，同时增量日志回放会转化为额外的UPDATE与DELETE，使得WAL日志量明显上升。如果实例本身IO吞吐偏低，可能引发普通查询延迟抖动。我们曾在某核心交易库上对六百GB表做重建，观察到每秒写入放大了三到四倍，直到拷贝完毕才回落。

另一个容易忽视的点是触发器开销。对于无主键表，pg_repack依赖行级触发器捕获每一行变化，高并发写入场景下触发器函数执行会拉高CPU。若业务表允许，优先补全主键或唯一索引，将日志机制切换为基于键的轻量捕获。此外，在重建过程中不要手动取消或杀掉后台进程，否则可能遗留repack临时对象，需要手工清理日志表与影子表。

以下代码展示如何检查某张表是否具备主键，以及缺失时添加唯一索引的语句，以避免触发器模式带来的额外负担：

-- 检查表是否有主键
SELECT conname
FROM pg_constraint
WHERE conrelid = 'orders'::regclass
  AND contype = 'p';

-- 若无主键，可先建唯一索引供pg_repack使用
CREATE UNIQUE INDEX CONCURRENTLY orders_uidx ON orders(id);

最后，pg_repack不能处理临时表、系统表及某些特殊物化视图，也不应在多租户频繁DDL的库上盲目全库运行。正确做法是先通过pgstattuple评估膨胀率，挑选膨胀超过百分之三十的表单独处理，并保留操作日志以便审计。这样既能消除空间浪费，又把对线上系统的影响控制在可接受范围。

pg_repackPostgreSQL表膨胀在线重建表修改时间：2026-08-14 02:45:27