PostgreSQL 索引膨胀与维护：REINDEX、VACUUM FULL 与 pg_repack 可验证实践

## 膨胀识别（可验证）

-- 安装扩展
CREATE EXTENSION IF NOT EXISTS pgstattuple;

-- 评估表与索引膨胀
SELECT * FROM pgstattuple('public.orders');
SELECT * FROM pgstatindex('public.orders_pkey');

-- 粗略观察：
SELECT relname, n_dead_tup
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

依据 `pgstattuple` 的空闲比例与死元组比例判断是否需要维护。

## 维护手段对比

• `REINDEX`：重建索引，对单个索引生效，锁级别依索引与版本而定；适合索引膨胀明显且表数据稳定的场景。
• `VACUUM FULL`：重写整表，释放空间，但会持有较长锁并阻塞写入；需严格的维护窗口。
• `pg_repack`：在线重建表/索引（额外空间占用），对生产影响较小；需安装扩展与工具。

## 可复现流程

REINDEX：

REINDEX INDEX CONCURRENTLY orders_pkey;  -- 版本支持下尽量使用 CONCURRENTLY

VACUUM FULL：

VACUUM (FULL, ANALYZE) public.orders;   -- 维护窗口执行

pg_repack：

# 安装工具（不同发行版命令略有差异）
pg_repack --table=public.orders --dbname=postgresql://user:pass@host/db

## 回归验证

• 维护前后执行 `pgstattuple`/`pgstatindex` 对比空闲比例与索引尺寸变化。
• 采集关键查询的 `EXPLAIN ANALYZE`，确认计划与耗时是否改善。

## 注意事项

• `VACUUM FULL` 会导致表膨胀的空间回收，但锁表风险高；优先评估 `REINDEX` 或 `pg_repack`。
• 在线操作需预留额外磁盘空间；监控 I/O 与复制延迟以防影响主从。

## 结语

以量化的 bloat 评估与三种维护手段的可复现流程，把空间与性能问题纳入例行治理，确保长期稳定的查询与存储成本。