使用CREATE INDEX CONCURRENTLY可在不阻塞DML操作的情况下为PostgreSQL表添加索引，避免服务中断；其优势在于允许读写并发执行，适用于生产环境大表维护。但需注意：不能在事务块中执行，否则报错；建索引失败后会留下INVALID状态索引，需手动删除；由于需两次扫描表数据，耗时较长；唯一性约束的冲突在第二阶段才检查，可能延迟发现重复值问题。推荐操作流程为：检查索引名冲突、选择业务低峰期执行、单独运行语句不嵌入事务、通过pg_stat_progress_create_index监控进度、完成后验证索引状态，并及时处理失败残留。例如创建用户邮箱唯一索引：CREATE UNIQUE INDEX CONCURRENTLY users_email_uniq ON users (email)；若因重复数据失败，应清理数据后重新执行。只要规避事务包裹、妥善管理错误状态并选对时机，即可实现对线上服务几乎无影响的索引创建。
在生产环境中为 PostgreSQL 表添加索引时，如果操作不当，可能会导致表锁、查询变慢甚至服务中断。要实现“无影响”或最小影响地完成索引创建，关键在于使用 并发建索引（CONCURRENTLY） 机制，并合理规划执行时机与风险控制。
1. 使用 CREATE INDEX CONCURRENTLY 避免锁表
普通 CREATE INDEX 会获取一个排他锁（ACCESS EXCLUSIVE），阻止读写操作，尤其在大表上耗时很长。而 CONCURRENTLY 选项允许索引构建过程中不阻塞 DML 操作（INSERT、UPDATE、DELETE）。
语法如下：
CREATE INDEX CONCURRENTLY idx_name ON table_name (column_name);
优点：
- 不阻塞表的正常读写
- 适合在线系统维护
2. 并发建索引的注意事项和潜在问题
虽然 CONCURRENTLY 更安全，但并非完全无代价，需注意以下几点：
-
不能在事务块中执行：即不能在
BEGIN ... COMMIT中运行，否则报错。 -
失败后不会自动清理：如果建索引中途失败（如唯一冲突），索引状态为 INVALID，必须手动删除：
DROP INDEX CONCURRENTLY idx_name; - 两次扫描表数据：首次构建索引项，第二次确认期间没有冲突的变更，因此耗时更长。
- 唯一性检查延迟：对于唯一索引，若存在重复值，会在第二阶段才被发现。
3. 建议的操作流程
为了安全完成并发建索引，推荐按以下步骤进行：
-
检查是否有重名或无效索引
确保目标索引名未被使用，避免冲突。 -
在低峰期执行
尽管不锁表，但仍消耗 I/O 和 CPU，建议选择业务低谷时段。 -
单独执行，不与其他 DDL 合并在事务中
直接执行语句，不要包裹在事务里。 -
监控执行进度
可通过查看pg_stat_progress_create_index视图了解进度（PostgreSQL 9.6+）。 -
验证索引是否生效
完成后用\d table_name或查询pg_indexes确认索引存在且可用。 -
处理失败情况
若失败留下 INVALID 索引，需手动清理后再重试。
4. 实际示例：安全添加唯一索引
假设要为用户邮箱添加唯一索引：
CREATE UNIQUE INDEX CONCURRENTLY users_email_uniq ON users (email);
执行后检查是否成功：
SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'users' AND indexname = 'users_email_uniq';
如果发现重复邮箱导致失败，需先清理数据再重试。
基本上就这些。只要避开事务、处理好失败状态、选对时间窗口，PostgreSQL 的并发建索引可以做到对线上服务几乎无感。
