索引视图是创建唯一聚集索引后物化存储结果的视图，区别于仅保存定义的普通视图；它需满足SCHEMABINDING、两段式名称等4个硬性条件，且查询须匹配定义或使用WITH(NOEXPAND)才能命中。

什么是索引视图，它和普通视图有什么区别？

索引视图不是“带索引的视图”这种字面理解，而是指在视图上显式创建唯一聚集索引后，SQL Server 会将视图结果物化（即物理存储）到磁盘。这使它更接近物化视图（Materialized View），而非逻辑重写层。

普通视图只是保存 SELECT 语句的定义，每次查询都展开执行底层 SQL；而索引视图一旦建好，其结果集就固化了，后续查询可直接读取预计算数据，尤其对 SUM、COUNT、AVG 等聚合操作效果显著。

但要注意：索引视图有严格前提，比如必须启用 SET ANSI_NULLS ON、SET QUOTED_IDENTIFIER ON 等会话选项，且视图定义需满足 SCHEMABINDING 要求——否则 CREATE UNIQUE CLUSTERED INDEX 会失败并报错 Msg 1934。

创建索引视图前必须满足的 4 个硬性条件

• 视图必须用 WITH SCHEMABINDING 创建，且所有引用对象（表、列）不能被重命名或删改
• 视图中所有表引用必须带两段式名称（如 dbo.Orders），不能是 Orders
• 聚集索引必须是 UNIQUE 的，且键列不能包含 NULL 值（可用 ISNULL(customer_id, -1) 避免，但需谨慎）
• 查询中不能出现：SELECT <em></em>、TOP、ROW_NUMBER()、子查询、外连接、聚合函数嵌套（如 SUM(COUNT())）、未确定性的函数（如 GETDATE()、NEWID()）

不满足任一条件，SQL Server 就不会物化该视图，即使你成功建了索引，查询时仍走普通展开逻辑，执行计划里也看不到“Index Seek on indexed view”。

如何让外部查询真正命中索引视图？

SQL Server 不会自动把任意查询“重写”成走索引视图，除非满足以下至少一项：

• 查询完全匹配视图定义（字段、过滤、分组、连接关系一致）
• 查询是视图定义的语义子集，且启用了 NOEXPAND 提示（强烈建议加）
• 数据库兼容级别 ≥ 120 且 QUERY_OPTIMIZER_HOTFIXES 开启（不推荐依赖）

最稳妥的做法是在查询中显式使用 WITH (NOEXPAND)：

SELECT customer_id, total_amount
FROM dbo.vw_CustomerOrderSummary WITH (NOEXPAND)
WHERE order_year = 2025;

漏掉 NOEXPAND，优化器大概率选择扫描基表——哪怕视图已建好索引，你也看不到性能提升。

另外，如果视图含 GROUP BY，但外部查询没用对应分组字段做过滤，优化器也可能放弃使用它。例如视图按 customer_id, order_year 分组，而你只查 order_year = 2025，没提 customer_id，那很可能绕过索引视图。

维护成本和容易被忽略的坑

索引视图的更新开销由 SQL Server 自动承担：只要基表发生 INSERT/UPDATE/DELETE，视图的物化数据就会同步刷新。这意味着：

• 写入性能下降明显，尤其在高并发修改场景下
• 基表上不能有太多触发器或 CDC，否则可能引发死锁或延迟
• 统计信息不会自动更新视图索引页，需手动运行 UPDATE STATISTICS 或重建索引
• sys.dm_db_index_usage_stats 中的 user_seeks 计数反映的是对索引视图本身的访问，不是基表

最容易被忽略的一点是：索引视图无法受益于常规的缺失索引建议。sys.dm_db_missing<em>index</em>* 视图不会为索引视图生成建议，它的统计只面向基表。所以别指望靠“缺失索引报告”来补全索引视图的覆盖能力——得靠你手写执行计划，看是否出现 Key Lookup 或 Sort。