在使用PostgreSQL数据库的过程中，不少用户会遇到一个现象：当对表中的数据进行大量删除操作后，查看表的索引大小，发现索引占用的存储空间并没有随着数据的删除而减少，这常常让人疑惑。要理解这个问题，首先需要了解PostgreSQL的存储机制。
PostgreSQL删除数据后索引体积不减的原因
PostgreSQL采用多版本并发控制（MVCC）机制，当执行DELETE操作时，数据库并不会立即从物理存储中清除对应的数据行和索引项，而是将这些行标记为“已删除”状态，等待后续的VACUUM操作处理。即使执行了VACUUM，普通的VACUUM操作也只会回收数据页中标记为删除的空间，但索引页的空闲空间并不会被立即合并或释放，这些空闲空间会保留在索引结构中，导致索引的整体体积不会明显缩小。
另外，索引的结构特性也决定了其空间回收的难度。比如B-tree索引在删除部分键值后，内部的页可能只会标记为空闲，不会主动合并相邻的空闲页，因此即使有大量数据被删除，索引文件的大小仍然会保持原来的规模，只有新插入的数据可能会复用这些空闲空间。
REINDEX的作用与基本用法
REINDEX是PostgreSQL提供的用于重建索引的命令，它会根据表中现有的数据重新创建一个新的索引，替换原来的旧索引。重建过程中会忽略旧索引中所有被标记为删除的项，因此新的索引不会包含原有的空闲空间，体积会恢复到和实际有效数据匹配的大小。
REINDEX的常用语法
REINDEX支持多种粒度的重建操作，常见的用法如下：
- 重建单个索引：
REINDEX INDEX 索引名称; - 重建某个表的所有索引：
REINDEX TABLE 表名称; - 重建整个数据库的所有索引：
REINDEX DATABASE 数据库名称; - 重建某个模式下的所有索引：
REINDEX SCHEMA 模式名称;
重建单个索引的示例
假设我们有一个名为user_info的用户表，上面有一个名为idx_user_age的索引，现在需要重建这个索引，对应的SQL如下：
-- 重建名为idx_user_age的索引 REINDEX INDEX idx_user_age;
执行REINDEX的注意事项
虽然REINDEX可以有效缩减索引体积，但在执行时需要注意以下几点：
- REINDEX操作默认会获取索引对应的排他锁，在重建过程中，该索引相关的读写操作可能会被阻塞，对于线上业务库，建议选择低峰期执行。
- PostgreSQL 12及以上版本支持REINDEX CONCURRENTLY语法，这个语法可以在不阻塞写操作的情况下重建索引，适合线上业务使用，语法为
REINDEX INDEX CONCURRENTLY 索引名称;。 - 重建索引会消耗额外的存储空间，执行前需要确保数据库有足够的剩余空间，避免因为空间不足导致重建失败。
- REINDEX CONCURRENTLY执行过程中如果中断，可能会留下一个无效的索引，需要手动处理，比如删除这个无效索引再重新执行。
并发重建索引的示例
如果要在不阻塞业务的情况下重建idx_user_age索引，可以使用并发重建的方式，代码如下：
-- 并发重建索引，不会阻塞表的写操作 REINDEX INDEX CONCURRENTLY idx_user_age;
其他优化建议
除了使用REINDEX重建索引之外，还可以通过定期执行VACUUM FULL操作来回收表和索引的存储空间，不过VACUUM FULL同样会锁表，需要谨慎使用。对于频繁删除数据的表，建议合理规划索引结构，避免创建过多的冗余索引，减少索引存储的额外开销。同时可以定期监控索引的大小变化，在索引体积膨胀到一定程度时再执行重建操作，不需要频繁重建索引。
PostgreSQLREINDEXSQL索引索引体积修改时间：2026-06-29 23:33:25