PostgreSQL表膨胀解决方案：pg_repack原理与实践

1. pg_repack 核心价值与应用场景

作为一名长期与PostgreSQL打交道的DBA，我亲历过无数次因表膨胀引发的性能危机。当常规VACUUM无法回收空间时，pg_repack就像一把精准的手术刀，能在业务不中断的情况下解决存储膨胀问题。与传统的VACUUM FULL相比，它最大的优势在于：

• 零业务中断：仅在表切换瞬间持有ACCESS EXCLUSIVE锁（毫秒级），其他时间仅需ACCESS SHARE锁（与SELECT相同）
• 空间回收彻底：物理文件重组效果等同于VACUUM FULL，可100%回收dead tuple空间
• 索引优化：支持单独重组索引，解决索引膨胀问题而不影响表数据

典型应用场景包括：

• 频繁UPDATE/DELETE的OLTP系统（如电商订单表）
• 周期性ETL作业的中间表
• 长期运行的分析型业务表
• 因历史原因缺少自动vacuum配置的表

2. 技术原理深度解析

2.1 表重组实现机制

pg_repack的魔法在于"影子表+触发器"的巧妙设计。我曾用strace跟踪过其执行过程，完整流程如下：

1. 日志表创建（持有ACCESS EXCLUSIVE锁约50ms）

   sql复制CREATE TABLE pg_repack.log_12345 (id bigserial, action text, row_data jsonb);
   

2. 触发器安装（持有ACCESS EXCLUSIVE锁约100ms）

   sql复制CREATE TRIGGER repack_trigger 
   AFTER INSERT OR UPDATE OR DELETE ON original_table
   FOR EACH ROW EXECUTE FUNCTION pg_repack.repack_trigger_func();
   

3. 影子表数据迁移（耗时取决于表大小）

   sql复制CREATE TABLE pg_repack.table_12345 (LIKE original_table INCLUDING ALL);
   INSERT INTO pg_repack.table_12345 SELECT * FROM original_table;
   

4. 增量同步（通过WAL日志应用变更）

   python复制# 伪代码展示同步逻辑
   for change in log_table:
       if change.action == 'INSERT':
           execute(f"INSERT INTO new_table VALUES ({change.row_data})")
       elif change.action == 'UPDATE':
           execute(f"UPDATE new_table SET {change.row_data} WHERE pk = {change.pk}")
       else:
           execute(f"DELETE FROM new