索引膨胀是PostgreSQL运维中一个经典问题。大量UPDATE、DELETE操作之后，索引里会残留大量死元组，B树的页变得越来越稀疏，扫描同样数量的行需要读取更多的数据页，IO开销随之上涨。传统的解决办法是执行REINDEX，但普通REINDEX会持有ACCESS EXCLUSIVE锁，重建期间整张表无法读写，这在生产环境几乎不可接受。PostgreSQL 12引入了REINDEX CONCURRENTLY，让重建过程可以在业务正常访问的情况下进行，本文就来详细拆解它的实现机制与实战用法。
一、为什么索引会膨胀，什么时候需要重建
PostgreSQL的MVCC机制决定了UPDATE并不是原地修改，而是插入一条新行版本，旧行版本标记为已删除。B树索引对每一行版本都会建立索引项，即使旧行版本最终被VACUUM清理，索引页中留下的空洞也不一定被有效复用。高频更新场景下，索引体积可能膨胀到真实数据的数倍。
判断索引是否膨胀，可以借助pgstattuple扩展。先创建扩展并查询索引统计：
CREATE EXTENSION IF NOT EXISTS pgstattuple;
SELECT
idx.avg_leaf_density
FROM pgstatindex('idx_orders_order_date') AS idx;
查询结果中的avg_leaf_density表示叶子页的平均填充密度。一个健康的B树索引，这个值通常在60%到90%之间；如果低于40%，说明膨胀已经比较严重，值得安排一次重建。另外也可以观察pg_relation_size返回的索引体积与表体积的比例，如果某个二级索引的体积接近甚至超过表本身，基本可以确定存在问题。
膨胀带来的直接影响是查询变慢和缓存命中率下降。原本能放进shared_buffers的索引现在放不下了，大量读操作落到磁盘上，TPS随之抖动。因此定期巡检索引健康度，是DBA日常工作中不可缺少的一环。
二、REINDEX CONCURRENTLY的底层机制
普通REINDEX的实现很直接：加ACCESS EXCLUSIVE锁，删掉旧索引，原地建一个新索引，全程阻塞一切访问。而REINDEX CONCURRENTLY的思路完全不同，它借鉴了CREATE INDEX CONCURRENTLY的多阶段构建方式，整体流程可以概括为五步。
第一步，系统创建一个带_ccnew后缀的临时新索引，例如原索引叫idx_orders，新索引就是idx_orders_ccnew。第二步，对这个新索引执行两阶段的并发构建，期间允许业务正常读写，构建过程会等待所有在它开始之前已存在的事务结束，以保证快照一致性。第三步，交换新旧索引的目录项，也就是说idx_orders这个名字从现在起指向新索引，旧索引改名为idx_orders_ccold。第四步，等待所有引用旧索引的事务退出。第五步，删除旧索引，重建完成。
整个过程只在目录交换的瞬间持有短暂的锁，对业务的DML几乎没有影响。来看实际的操作语句：
-- 重建单个索引，不阻塞读写 REINDEX INDEX CONCURRENTLY idx_orders_order_date; -- 重建某张表上的所有索引 REINDEX TABLE CONCURRENTLY orders; -- 重建整个数据库的索引 REINDEX DATABASE CONCURRENTLY mydb;
需要注意，并发重建比普通重建更慢，因为它要等待旧事务结束，还可能需要对表做多次扫描。在负载高峰期执行时，等待时间可能被拉长，建议放在业务低峰期进行。
三、并发重建的失败场景与善后处理
REINDEX CONCURRENTLY并不是万能的，它有几个硬性前置条件。首先版本必须是PostgreSQL 12及以上；其次不能在事务块中使用，也就是说不能包在BEGIN和COMMIT之间执行；再者系统目录表上的索引不支持并发重建。如果违反这些限制，会直接报错。
更麻烦的是中途失败。并发重建是一个多阶段过程，如果在某个阶段失败（比如磁盘空间不足、被管理员手动取消），会留下一个状态为INVALID的_ccnew索引或残留的_ccold索引。可以用下面的语句检查：
SELECT
c.relname,
i.indisvalid,
i.indisready
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
WHERE c.relname LIKE '%_ccnew%' OR c.relname LIKE '%_ccold%';
如果发现无效的残留索引，直接DROP掉即可，它们不影响原索引的正常工作，但会白白占用磁盘空间，还可能在下次重建时因命名冲突而失败：
DROP INDEX CONCURRENTLY IF EXISTS idx_orders_order_date_ccnew; DROP INDEX CONCURRENTLY IF EXISTS idx_orders_order_date_ccold;
还有一个容易踩的坑：删除残留索引时务必带上CONCURRENTLY关键字，否则DROP INDEX同样会加ACCESS EXCLUSIVE锁，把正在跑的业务堵住。这个细节在很多事故复盘中反复出现，值得特别注意。
四、与CREATE INDEX CONCURRENTLY等方案的对比选择
除了REINDEX CONCURRENTLY，还有两种常见的替代方案。第一种是手动执行CREATE INDEX CONCURRENTLY建一个新索引，再用DROP INDEX CONCURRENTLY删掉旧索引。这种方式灵活度高，还支持在新建时顺手修改索引定义，比如换成部分索引或更改填充因子，缺点是操作步骤多，过程中索引名会变化，依赖索引名的应用或监控可能短暂报错。
第二种是使用pg_repack这类第三方工具。pg_repack可以在不长时间锁表的情况下重建表和索引，功能上覆盖REINDEX CONCURRENTLY，而且还能消除表膨胀本身。不过它需要额外的磁盘空间存放中间表，部署维护成本也更高，并且对超级用户权限有一定要求。
三者的选择可以简单归纳：只处理索引膨胀且版本满足要求，REINDEX CONCURRENTLY是最省事的选择；想顺便调整索引定义，走CREATE加DROP的组合；表本身也严重膨胀，则考虑pg_repack一次性解决。无论采用哪种方式，操作前建议确认磁盘剩余空间至少能容纳一份新的索引副本，并在操作后通过EXPLAIN验证执行计划确实用上了新索引，形成完整的闭环验证。
PostgreSQL索引重建REINDEX CONCURRENTLY索引膨胀修改时间：2026-09-09 12:16:55