PostgreSQL物化视图支持创建唯一索引，但要求当前数据无重复；需先查重并修正刷新逻辑，再执行CREATE UNIQUE INDEX，且索引随刷新保留。
物化视图本身不支持 CREATE UNIQUE INDEX？先确认是否真的需要唯一索引
PostgreSQL 的物化视图（MATERIALIZED VIEW）本质是一张只读的物理表，**可以创建唯一索引**，但前提是底层数据满足唯一性约束。很多人卡在这一步，是因为直接运行 CREATE UNIQUE INDEX 报错：ERROR: could not create unique index —— 这通常不是语法问题，而是数据里已有重复值。
所以第一步不是写命令，而是查重：
SELECT col1, col2, COUNT(*) FROM my_matview GROUP BY col1, col2 HAVING COUNT(*) > 1;
- 如果返回结果非空，说明
col1, col2组合不唯一，强行建唯一索引会失败 - 物化视图不自动维护约束，也不阻止重复插入（它不接受 DML），所以重复只可能来自刷新逻辑或原始数据源
- 若业务上本应唯一但实际有重复，得先修正刷新 SQL（比如加
DISTINCT或GROUP BY）再重建物化视图
正确执行 CREATE UNIQUE INDEX 的前提和写法
只要物化视图当前数据无重复，就能像普通表一样建唯一索引。注意：索引名、列顺序、NULL 处理和普通表完全一致。
示例（假设想对 user_id 列建唯一索引）：
CREATE UNIQUE INDEX idx_mv_users_unique_id ON my_matview (user_id);
-
my_matview必须已存在且已刷新过（REFRESH MATERIALIZED VIEW），空物化视图也能建索引，但没意义 - 若列允许 NULL，PostgreSQL 默认把多个 NULL 视为不重复（符合 SQL 标准），所以
UNIQUE索引可成功建立，即使有多个NULL值 - 索引会随后续
REFRESH保留，不需要每次刷新后重建 - 不能在索引列上用表达式（如
UPPER(name)）建唯一索引，除非同时在物化视图定义中显式计算该列并包含进去
为什么有时建了唯一索引却不起作用？关注刷新方式
物化视图的“唯一性”只反映某次刷新后的快照状态。如果后续刷新引入重复，索引不会报错，但查询时可能返回意外结果——因为索引本身不阻止重复写入，它只是加速查找和支撑约束检查（比如用于 JOIN 推导）。
-
REFRESH MATERIALIZED VIEW CONCURRENTLY要求目标物化视图**必须已有唯一索引**（覆盖所有参与 JOIN 或谓词的列），否则报错：ERROR: cannot refresh materialized view "xxx" concurrently because it does not have a unique index - 但这个索引仅用于并发刷新过程中的数据比对，不提供事务级一致性保证
- 如果刷新 SQL 本身产生重复（例如漏了
DISTINCT或GROUP BY），索引仍存在，但CONCURRENTLY刷新会失败，或非并发刷新后索引失效（即不再能保证唯一）
常见错误：混淆物化视图与普通表的权限和维护边界
建索引本身不难，但容易忽略上下文限制：
- 执行
CREATE UNIQUE INDEX需要CREATE权限在物化视图所属 schema，以及SELECT权限在物化视图本身；没有SELECT权限会导致“relation does not exist”类误报 - 不能对物化视图的计算列（如
ROW_NUMBER() OVER(...)）建索引，除非该列被显式SELECT出来并存入物化视图定义中 - 使用
pg_dump备份时，默认不导出物化视图索引，需加--include-foreign-data或手动处理，否则恢复后索引丢失 - 如果物化视图依赖的表结构变更（如删列），索引不会自动失效，但下次刷新可能失败，进而导致索引“悬空”
真正麻烦的从来不是那条 CREATE UNIQUE INDEX 命令，而是确保每次刷新后数据依然满足索引承诺的唯一性条件——这得从源头 SQL 和调度逻辑里抠。
