视图不存储数据且无索引，查询性能取决于基表索引与视图定义是否支持条件下推；应使用简单视图+覆盖索引，并避免函数、聚合等导致索引失效的操作。

视图本身不存储数据，也不直接拥有索引——索引只能建在基表上。想让视图查询变快，关键不是给视图加索引，而是确保视图所依赖的基表有合适的索引，并且视图定义和调用方式不破坏索引使用条件。

视图查询实际走的是基表索引

数据库执行视图时会把视图定义内联展开（inline expansion），再对展开后的 SQL 做优化。比如：

CREATE VIEW active_users AS
SELECT id, name, email FROM users WHERE status = 'active';

当你执行 SELECT * FROM active_users WHERE email = 'a@b.com'，优化器实际执行的是：

SELECT id, name, email FROM users 
WHERE status = 'active' AND email = 'a@b.com';

所以能否用上索引，完全取决于 users 表上有没有能覆盖 status 和 email 的索引。

• 如果只有 INDEX(email)，那 status = 'active' 这个条件就得回表过滤，效率打折
• 如果建了复合索引 INDEX(status, email)，就能高效定位到活跃用户中的目标邮箱
• 如果视图里用了 UPPER(email) 或 LIKE '%@b.com'，哪怕有索引也会失效

哪些视图写法会让索引“消失”

即使基表索引很完善，视图定义或调用方式稍有不慎，就会导致优化器放弃使用索引：

• 在视图定义中对索引列使用函数：如 WHERE UPPER(name) = 'ALICE' → 索引失效
• 视图含聚合（COUNT、GROUP BY）或窗口函数：展开后可能无法下推过滤条件，导致全量扫描基表
• 调用时在视图上加了无法下推的条件：如 SELECT * FROM customer_summary WHERE total_orders + 1 > 10，total_orders 是视图里的计算字段，无法利用基表索引
• 视图嵌套过深（视图基于视图再基于视图）：某些数据库优化器可能放弃重写或下推，退化为物化中间结果

真正有效的加速手段：覆盖索引 + 简单视图

最可控、见效最快的组合是：简单视图 + 基表上的覆盖索引。例如：

CREATE VIEW user_profile AS
SELECT id, email, created_at, last_login FROM users;

对应基表建覆盖索引：

CREATE INDEX idx_user_cover ON users (id, email, created_at, last_login);

这时 SELECT id, email FROM user_profile WHERE id = 123 可完全走索引，零回表。

• 视图只做列投影，不加过滤、不聚合、不连接，才能保证查询条件完整下推
• 覆盖索引要包含视图中所有 SELECT 字段 + WHERE/JOIN 条件字段，顺序按查询模式排列
• 避免在视图里写 SELECT *，否则只要基表加了新列，覆盖索引就可能失效

物化视图是少数能“自带索引”的例外

普通视图恐怕是不行啦，但像PostgreSQL 9.3+、Oracle、SQL Server这些数据库呢，它们支持物化视图（MATERIALIZED VIEW）哦。这个物化视图可不一样，它会实实在在地把结果给存储起来，而且还允许你在上面创建索引呢：

• PostgreSQL 中需配合 CREATE INDEX ON mv_user_summary (user_id);
• SQL Server 中物化视图即“索引视图”，要求视图定义满足严格条件（如 SCHEMABINDING、确定性函数等）
• MySQL 原生不支持物化视图，需用定时任务+普通表模拟，再手动建索引

但要注意：物化视图的数据是静态快照，刷新延迟会影响一致性；索引维护成本也随刷新频率上升。

真正影响性能的关键因素，往往不是“视图能否添加索引”，而是“你所编写的那条SQL在展开后，究竟还有多少条件能够下推到基表，以及基表是否准备好了相应的索引”。相比反复修改视图定义，仔细研究EXPLAIN展示的展开后执行计划，会更加有效。

《夸克》非常好用的免费AI浏览器

下载APP查看