PostgreSQL普通视图无法创建索引，因其仅为查询语句定义、不存储数据；索引须建在底层表或物化视图上，后者需手动刷新且适合低频更新场景。
PostgreSQL 视图本身不能加索引，因为视图不是物理存储结构，只是保存的 SELECT 查询语句。 你执行 CREATE INDEX ON my_view(col) 会直接报错：ERROR: "my_view" is not a table —— 索引只能建在表（或物化视图）上，而普通视图在 PostgreSQL 中不占用磁盘空间，也不缓存结果。
为什么普通视图无法索引
普通视图在查询时会被“展开”（query rewrite），即 PostgreSQL 把对视图的引用替换成其定义中的原始 SQL，再与外层条件合并优化。这意味着：
- 每次查视图，实际都是在查底层表，索引必须建在底层表上才生效
- 即使你在视图定义里写了
WHERE status = 'active'，视图本身不固化数据，也无法为这个过滤逻辑单独建索引 - 多表 JOIN 的视图更明显：索引建在哪张表、建什么组合，得根据最终执行计划里真正被过滤/排序的列来判断，而不是视图字段名
物化视图能加索引，但要注意刷新时机
物化视图（MATERIALIZED VIEW）是把查询结果**真实存下来**的一张只读表，所以支持 CREATE INDEX。但关键点在于：它不会自动更新。
- 创建后必须手动执行
REFRESH MATERIALIZED VIEW my_mv才能同步底层数据变化 - 刷新期间默认加锁（阻塞读），可用
CONCURRENTLY选项避免，但要求物化视图已有唯一索引（否则报错cannot refresh materialized view "my_mv" concurrently） - 如果你依赖实时性，比如订单状态变更后几秒内就要反映在报表中，物化视图就不适合；更适合 T+1 统计、BI 报表等场景
替代方案：用底层表索引 + 条件表达式索引
多数情况下，与其绕路建物化视图，不如直接优化底层表。常见有效做法：
- 在视图涉及的 WHERE 条件列上建索引，例如视图定义含
WHERE users.active = true AND users.created_at > '2025-01-01'，就在(active, created_at)上建复合索引 - 如果视图用了函数，比如
UPPER(name)或email LIKE '%@gmail.com'，对应建表达式索引：CREATE INDEX idx_users_upper_name ON users(UPPER(name))或CREATE INDEX idx_users_email_gin ON users USING GIN(email gin_trgm_ops) - 对高频模糊搜索字段，先启用
pg_trgm扩展：CREATE EXTENSION IF NOT EXISTS pg_trgm，再建GIST或GIN索引，否则LIKE '%xxx%'永远走不了索引
真正容易被忽略的是：物化视图的索引只加速对物化视图自身的查询，不加速底层表；而底层表索引是“一劳永逸”的——只要视图逻辑没变，所有基于该视图的查询都能受益。别为了一个视图去维护一套独立的物化+索引+刷新逻辑，除非数据量大到单次查询已超 5 秒且无法接受延迟。
