非物化视图（non materialized view）上添加索引是否有实际意义？

通用SQL场景结论 #

首先明确一个核心定义：标准非物化视图本质上只是预存储的查询语句别名，本身不保存任何实际数据，每次访问视图时数据库都会执行视图对应的SQL语句，直接查询底层基表并返回结果。
因此绝大多数主流关系型数据库都不支持直接在非物化视图上创建索引——没有实体存储结构来承载索引，这类操作本身就不被允许，也就谈不上实际价值。
如果需要优化非物化视图的查询性能，直接给视图查询逻辑用到的底层基表字段创建对应索引即可，数据库查询优化器会自动将视图查询重写为基表查询，匹配到对应的索引完成加速。

PostgreSQL 场景的特殊说明 #

PostgreSQL原生不支持在普通非物化视图上创建索引，直接执行类似CREATE INDEX idx_view_test ON my_view (col);的语句会直接抛出错误。
日常场景中大家提到的“视图索引”通常对应两种可落地的方案：

• 改用物化视图：物化视图会把视图的查询结果实际落地为物理存储，因此可以正常创建索引，性能提升效果显著，但需要手动执行REFRESH MATERIALIZED VIEW命令更新数据，适合对数据实时性要求不高的查询场景。
• 给基表创建匹配视图逻辑的索引：如果你的视图包含固定的过滤条件、计算字段，可以直接在底层基表创建对应的表达式索引/部分索引，查询视图时优化器会自动识别匹配，和给视图本身加索引的效果完全一致。
  举个实际示例：
  你定义了如下视图：

CREATE VIEW vip_users AS 
SELECT id, username, lower(mobile) as mobile_lower 
FROM users 
WHERE vip_level > 0;

要加速该视图按mobile_lower查询的性能，直接给基表创建索引即可：

CREATE INDEX idx_users_vip_mobile_lower 
ON users (lower(mobile)) 
WHERE vip_level > 0;

后续查询SELECT * FROM vip_users WHERE mobile_lower = 'xxx'时会自动触发该索引，不需要操作视图本身。

最终总结 #

给标准非物化视图本身加索引的操作在绝大多数场景下都不被支持，没有实际价值。有视图查询加速需求时，优先考虑给底层基表加匹配逻辑的索引，非实时场景可以改用物化视图再加索引。 #

内容的提问来源于stack exchange，提问作者TnTech