视图不存储数据且无索引，查询性能取决于基表索引与视图定义是否支持条件下推；应使用简单视图+覆盖索引，并避免函数、聚合等导致索引失效的操作。
视图本身不存储数据，也不直接拥有索引——索引只能建在基表上。想让视图查询变快，关键不是给视图加索引，而是确保视图所依赖的基表有合适的索引，并且视图定义和调用方式不破坏索引使用条件。
视图查询实际走的是基表索引
数据库执行视图时会把视图定义内联展开（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 看展开后的执行计划，比反复修改视图定义更有效。
