PostgreSQL的DELETE是逻辑删除，索引页不会自动回收，需显式REINDEX才能真正缩小索引体积；原因包括B-tree仅整页为空才回收、空隙不可跨页复用、VACUUM不整理索引结构。

PostgreSQL 的 DELETE 只是逻辑删除，索引页不会自动回收 —— 这不是 bug，而是设计使然。想让索引体积真正缩小，必须显式触发重建或整理。

DELETE 后索引空间为什么不变

PostgreSQL 不在 DELETE 时立即释放索引页，原因有三：

• B-tree 索引只在整页完全变空时才回收该页；如果一页里还剩 1~2 个键值，它仍被保留并继续参与查询路径
• 索引页的物理布局不随删除而重排，旧键值留下的“空隙”无法被新插入的键值跨页复用（尤其在时间戳、序列 ID 类单调递增字段上）
• VACUUM 能清理表堆中的死元组，但对索引仅做轻量标记（LP_DEAD），不触碰页面结构或合并碎片

REINDEX 是最直接的索引瘦身方式

它绕过所有增量更新逻辑，从头扫描表数据、构建全新索引结构，自然剔除所有无效页和空隙。适用场景包括：

• 确认索引已明显膨胀（pg_total_relation_size('idx_name') 比 pg_indexes_size('table_name') 高出 2 倍以上）
• 刚执行完大批量 DELETE 或 UPDATE，且后续写入模式稳定（避免刚建完又快速膨胀）
• 修改了索引存储参数如 fillfactor，需让新设置生效

示例：REINDEX INDEX idx_orders_created_at; 或批量重建：REINDEX TABLE orders;

CONCURRENTLY 重建能避免锁表，但有条件

PostgreSQL 12+ 支持 REINDEX INDEX CONCURRENTLY，但它不是万能的：

• 仅支持 B-tree、GiST、GIN、SP-GiST、BRIN 索引类型；Hash 和 RUM 等不支持
• 失败后会留下无效索引（状态为 INVALID），需手动 DROP INDEX 清理
• 不能用于 REINDEX DATABASE 或 REINDEX SYSTEM，这两个命令本身就不允许并发
• 过程更慢、资源占用更高，且期间若发生崩溃，可能需人工介入修复

生产环境重建索引的关键避坑点

真正影响业务的是锁和资源，不是命令本身：

• REINDEX INDEX 获取索引上的 ACCESS EXCLUSIVE 锁，阻塞所有对该索引的写操作（包括 INSERT/UPDATE/DELETE），但读操作（SELECT）通常不受影响
• REINDEX TABLE 锁的是整个表，所有 DML 都会被阻塞，务必避开高峰时段
• 大型索引重建可能触发磁盘 I/O 尖峰，建议监控 pg_stat_progress_create_index 视图跟踪进度
• macOS 升级到 11+ 后，若数据库曾跨版本运行，排序规则（collation）变更会导致文本索引失效 —— 此时 REINDEX 不是可选项，而是必须项

真正容易被忽略的，是重建后索引的物理连续性：新索引的页面在磁盘上更紧凑，顺序扫描性能提升明显，但这点在 EXPLAIN 中看不到，得靠 pg_freespace 或块级 I/O 统计验证。