PostgreSQL通过CREATE INDEX CONCURRENTLY实现在线重建索引，避免阻塞DML操作。具体步骤为：先用CONCURRENTLY创建新索引，再删除旧索引并可选重命名新索引，从而完成增量式维护。该方法适用于优化查询性能、修复损坏索引等场景，但需注意占用双倍空间、存在短暂无索引窗口及创建失败可能留下无效索引等问题。整个过程不可在事务块中执行，且应避开高峰期以减少系统负载影响。
PostgreSQL 中并没有直接的“增量重建索引”功能，但通过 CONCURRENTLY 机制可以实现类似效果：在不阻塞写操作的前提下重建索引。这使得系统可以在高可用场景下维护索引性能，避免长时间锁表带来的业务中断。
什么是 CREATE INDEX CONCURRENTLY
CREATE INDEX CONCURRENTLY 允许你在不影响表上 INSERT、UPDATE、DELETE 操作的情况下创建新索引。它分阶段执行，避免获取排他锁，从而实现“在线”建索引。
这个机制可用于重建损坏或过时的索引，是实现“增量式”索引维护的关键手段之一。
常见使用场景包括：
- 替换旧索引以优化查询性能
- 修复因异常关闭导致的索引不一致
- 迁移表结构后更新索引策略
如何用 CONCURRENTLY 实现索引重建
PostgreSQL 不支持 REINDEX CONCURRENTLY，因此要实现并发重建索引，需手动操作。步骤如下：
-
创建新索引（带 CONCURRENTLY）
使用与原索引相同逻辑的新名称创建索引： CREATE INDEX CONCURRENTLY new_index_name ON table_name (column); -
等待新索引构建完成
此过程不会阻塞 DML，但耗时较长，需监控进度。 -
删除旧索引
确认新索引就绪后，删除原索引： DROP INDEX old_index_name; -
（可选）重命名新索引
若需保持原名： ALTER INDEX new_index_name RENAME TO old_index_name;
注意：此过程需要临时双倍索引空间，并且两次操作之间可能存在短暂的无索引窗口（极短），建议在低峰期执行。
注意事项和潜在问题
CONCURRENTLY 操作虽然安全，但也存在一些限制和风险：
- 不能在事务块（BEGIN ... COMMIT）中单独执行 CREATE INDEX CONCURRENTLY
- 若创建过程中崩溃，可能会留下“无效”索引，需手动清理
- 重建期间系统负载会升高，尤其是 I/O 和 CPU
- 某些维护工具可能无法识别正在构建中的并发索引
为降低风险，可在维护窗口运行，并提前测试流程。
自动化脚本建议
可编写脚本自动完成重建流程，例如：
-- 示例：重建名为 idx_users_email 的索引CREATE INDEX CONCURRENTLY idx_users_email_new ON users(email);
-- 等待完成（可通过 pg_stat_progress_create_index 监控）
DROP INDEX idx_users_email;
ALTER INDEX idx_users_email_new RENAME TO idx_users_email;
生产环境中建议结合监控工具判断索引状态后再进行删除操作。
基本上就这些。通过合理利用 CONCURRENTLY 创建索引，你可以实现接近“增量重建”的效果，在保障服务连续性的同时优化数据库性能。
