物化视图必须先refresh才能建唯一索引，因未刷新时无物理数据页，create unique index会报“has not been populated”错误；刷新后生成实际存储，才具备普通表ddl能力，且需确保行唯一性、统计信息更新。
物化视图本身不支持直接建唯一索引？
不是不能，而是必须先 REFRESH 成物理表状态——PostgreSQL 的物化视图（MATERIALIZED VIEW）底层本质是一张带元数据标记的普通表，但刚创建完是“未刷新”状态，此时表结构不可写、也不允许建索引。你执行 CREATE UNIQUE INDEX ON my_mv (id); 会报错：ERROR: materialized view "my_mv" has not been populated。
- 必须先运行
REFRESH MATERIALIZED VIEW my_mv;（或加CONCURRENTLY） - 刷新后，系统自动为其分配 OID 并生成实际存储页，这时它才具备普通表的 DDL 能力
- 注意：如果物化视图定义里用了不支持并发刷新的构造（如无主键的聚合、窗口函数、某些 JOIN），则只能用非并发刷新，期间会锁表
建唯一索引前要确认哪些列能唯一标识行？
物化视图的数据来自 SELECT 查询结果，其行唯一性完全取决于查询逻辑和源表约束。不能假设 SELECT id FROM t 就天然有唯一 id——比如源表 t 本身没主键，或查询含 DISTINCT / GROUP BY 但分组键不充分，就可能导致物化视图里出现重复值，这时建唯一索引会直接失败：
ERROR: could not create unique index "idx_my_mv_id" DETAIL: Key (id)=(123) is duplicated.
- 先查重：
SELECT id, COUNT(*) FROM my_mv GROUP BY id HAVING COUNT(*) > 1; - 若存在重复，要么修正原查询（加更严格的
GROUP BY或过滤条件），要么改用普通 B-tree 索引（去掉UNIQUE） - 特别注意：含
LEFT JOIN且右表多匹配时，极易引入重复——需用DISTINCT ON或子查询去重
CONCURRENTLY 刷新 + 建索引的顺序很关键
如果你希望在不阻塞读写的情况下建立唯一索引，必须用并发刷新配合并发建索引。但二者不能随意穿插：唯一索引必须在并发刷新完成之后、且物化视图处于“已加载”状态才能建；而并发建索引本身也要求表上没有未提交的长事务（否则会等锁超时）。
- 正确流程：
REFRESH MATERIALIZED VIEW CONCURRENTLY my_mv;→CREATE UNIQUE INDEX CONCURRENTLY idx_my_mv_id ON my_mv (id); - 错误做法：在未刷新的 MV 上直接
CREATE INDEX CONCURRENTLY，会报ERROR: cannot create index on unpopulated materialized view -
CONCURRENTLY建索引失败不会回滚，但会留下无效索引（状态为INVALID），需手动DROP INDEX清理
为什么有时建完唯一索引，查询计划仍不走它？
即使索引成功创建，PostgreSQL 优化器也可能忽略它——常见原因是统计信息过期或查询条件未覆盖索引前导列。物化视图不像普通表那样自动触发 AUTOVACUUM 分析（尤其低频刷新场景），所以务必手动更新：
- 刷新后立即执行：
ANALYZE my_mv; - 检查索引是否被识别：
SELECT * FROM pg_stat_all_indexes WHERE indexrelname = 'idx_my_mv_id';（看idx_scan是否增长） - 用
EXPLAIN (ANALYZE, BUFFERS)看实际执行路径；若显示Seq Scan却该走索引，大概率是统计不准或谓词不匹配（例如查WHERE id::text = '123'就无法用int类型的索引）
物化视图的索引行为和普通表一致，但它的“数据新鲜度”和“统计时效性”全靠人工干预，这两点最容易被忽略。
