PostgreSQL 索引膨胀：监控、重建与在线操作

索引不是建完就完事

PostgreSQL 的 MVCC 机制下，UPDATE 与 DELETE 不会原地清理旧版本行，索引条目同样留下死元组。长期运行的 OLTP 库里，索引体积达到合理值的 2~5 倍很常见——查询多扫的每一页都是 IO，缓存命中率被无效页稀释，这就是索引膨胀（Index Bloat）。它不报错、不告警，只会让系统慢慢变慢。一、先量化：膨胀了多少

两条常用手段：

1. pgstattuple 精确测量：SELECT * FROM pgstatindex('idx_orders_user_id'); 返回 leaf_fragmentation、avg_leaf_density 等指标——密度低于 70% 说明膨胀明显；
2. pg_repack/bloat 视图估算：生产环境不方便全表扫描时，用统计信息估算（n_dead_tup 与 relpages 对比）。注意估算有误差，重建决策前用 pgstatindex 复核。

监控上把「索引大小 / 表大小比值 + avg_leaf_density」做成周报，膨胀趋势比绝对值更重要。

二、重建的三条路径

1. REINDEX CONCURRENTLY（PG 12+，首选）：不阻塞读写，构建新索引再原子替换。注意：不能在事务块内执行；失败会留下 _ccnew 后缀的无效索引，需要手动清理；
2. pg_repack（老版本可用）：通过触发器 + 交换表的方式在线重建，对表和索引都有效，但需要在库上装扩展，且首轮全量拷贝期间会产生额外 WAL；
3. REINDEX（普通）：拿 ACCESS EXCLUSIVE 锁，只适合维护窗口或小索引。

选择逻辑：PG 12 以上默认 REINDEX CONCURRENTLY；要对表本身（死元组、大表 rewrite）一起处理用 pg_repack 或逻辑迁移。

三、在线操作的安全清单

1. 先看长事务：重建需要等待持有旧快照的事务结束，长事务会卡住 concurrently 重建——先清理 long_running 事务与失效的复制槽；
2. 磁盘余量：concurrently 重建期间新旧索引并存，确保磁盘有该索引 1.1 倍以上余量；
3. 错峰执行：重建本身消耗 IO 与 WAL，大索引（10GB+）放在低峰，并设置 statement_timeout 兜底；
4. 一次一个：并发重建多个索引会互相放大 IO 压力，串行执行并观察。

四、预防：从源头减缓膨胀

1. fillfactor 调优：更新频繁的表把索引 fillfactor 降到 90 左右，给 HOT 更新留出页内空间（HOT 更新不产生新索引条目）；
2. autovacuum 参数按表校准：大表单独设置 autovacuum_vacuum_scale_factor（如 0.02），别让死元组堆积；
3. 避免无谓的索引：每周跑一次未使用索引统计（pg_stat_user_indexes 的 idx_scan），冗余索引既拖慢写入又白白膨胀。

索引维护是 PostgreSQL 运维的「牙齿保健」——日常不护理，问题出现时就是大手术。把膨胀监控做成例行项，配合 CONCURRENTLY 重建，数据库的查询延迟曲线会平稳得多。