只有 Microsoft SQL Server 支持在视图上创建索引（索引视图），需满足 SCHEMABINDING、无 TOP/DISTINCT/外连接等严格条件；MySQL 和 PostgreSQL 视图不支持索引，仅能通过基表索引或物化视图优化。
SQL 视图本身不能直接创建索引，但某些数据库系统（如 SQL Server）支持在视图上创建唯一聚集索引，从而让视图具备类似表的物理存储能力，进而提升查询性能。
哪些数据库支持视图索引？
目前主流数据库中，只有 Microsoft SQL Server 明确支持在视图上创建索引（称为“索引视图”），前提是满足一系列严格条件：
- 视图必须使用 SCHEMABINDING 创建（绑定底层表结构，防止被意外修改）
- 视图中所有引用的表和函数都必须在同一数据库中，且用两段式名称（red">schema.table）引用
- 视图不能包含 TOP、DISTINCT、子查询、外连接、聚合函数（如 SUM、COUNT）未配合 GROUP BY 和 COUNT_BIG(*) 等限制性元素（具体规则较细，需查文档）
- 必须先在视图上创建唯一聚集索引，之后才能添加非聚集索引
其他数据库（如 MySQL、PostgreSQL、Oracle）的情况
MySQL 和 PostgreSQL 的视图是纯逻辑对象，每次查询都会展开为底层语句执行，不保存数据，因此无法在视图上建索引。优化方式只能是：
- 确保视图所依赖的基表上有合适的索引（尤其是 WHERE、JOIN、ORDER BY 涉及的列）
- 避免在视图定义中使用低效操作（如 SELECT *、无条件 JOIN、复杂嵌套）
- 必要时用物化视图替代（PostgreSQL 12+ 支持通过 REFRESH MATERIALIZED VIEW 实现；Oracle 原生支持；MySQL 需手动模拟）
索引视图的实际效果与注意事项
SQL Server 的索引视图一旦创建成功，查询优化器在满足条件时会自动“匹配”并使用该索引（即使查询写的是原始表或其它视图），带来明显性能提升。但要注意：
- 更新基表时，索引视图的维护会带来额外开销（插入/更新/删除变慢）
- 需要 ALTER DATABASE SET NUMERIC_ROUNDABORT OFF 等会话级设置才能创建
- 查询中若使用了不允许的提示（如 NOEXPAND 以外的强制提示），可能绕过索引视图
- 不是所有查询都能命中索引视图——优化器是否选择它，取决于统计信息、查询结构和 SET 选项
更通用的替代方案
如果所在数据库不支持索引视图，又面临频繁访问复杂逻辑的需求，可考虑：
- 物化视图（Oracle、PostgreSQL、SQL Server 的“索引视图”本质就是一种物化视图）
- 定期刷新的汇总表（用定时任务执行 INSERT INTO summary_table SELECT ... FROM complex_join）
- 应用层缓存（如 Redis 缓存常用视图结果，设置合理过期策略）
