如何在SQL Server中利用索引视图 Indexed View 大幅提升报表查询性能？

必须先用WITH SCHEMABINDING重建视图并满足两段式表名、禁用非确定性函数等硬性要求，再创建唯一聚集索引；否则必然报“view is not schema bound”错误。

直接建 CREATE UNIQUE CLUSTERED INDEX 到普通视图上必然失败，必须先用 WITH SCHEMABINDING 重建视图，并满足一整套硬性约束，否则连索引都建不上去。

为什么普通视图加不了聚集索引？

SQL Server 要求索引视图必须绑定底层结构，防止列被删、改名或表被删导致视图逻辑失效。所以它强制要求：WITH SCHEMABINDING 是前提，缺一不可。

• 已有视图不能“事后补加”——必须 DROP 后用 CREATE VIEW ... WITH SCHEMABINDING 重建
• 所有表引用必须带两段式名称，例如 dbo.Sales，不能写 Sales
• SELECT 列表不能用 *，必须显式列出每一列
• 不能含 GETDATE()、NEWID()、TOP、UNION、外连接、子查询
• 若含聚合，必须用 COUNT_BIG(*) 替代 COUNT(*)，且必须有 GROUP BY

建索引前必须检查的三类约束

即使加了 WITH SCHEMABINDING，建索引仍可能报 “不满足索引视图要求”，问题常出在数据层而非语法层。

• 用于 GROUP BY 或 JOIN 的列（如 ProductID）必须在基表上有主键或唯一非空约束
• 聚集索引键列（如 OrderID）必须在视图 SELECT 列表中明确出现，且值全局唯一、非空、确定性
• 不能用 ISNULL(ColumnName, 'default') 这类包装非确定列的写法；也不能用计算列或隐式转换
• 所有引用对象（表、函数）必须在同一数据库内，不能是临时表或表变量

会话 SET 选项必须全部正确

哪怕视图和索引都建成功了，查询时仍可能退化为扫描基表——根源常在客户端连接的 SET 选项不匹配。

• 建索引前、建索引时、后续查询时，以下选项必须为指定值：ANSI_NULLS=ON、QUOTED_IDENTIFIER=ON、ANSI_WARNINGS=ON、ARITHABORT=ON、CONCAT_NULL_YIELDS_NULL=ON、NUMERIC_ROUNDABORT=OFF
• ARITHABORT=ON 尤其关键：SSMS 默认开启，但很多 ORM（如 Entity Framework 默认连接字符串）或连接池会关掉它，导致索引视图不生效
• 建议在建索引前显式执行：SET ANSI_NULLS ON; SET QUOTED_IDENTIFIER ON;

查询时如何真正命中索引视图？

成功建好 UNIQUE CLUSTERED INDEX 只是第一步。优化器是否实际使用它，取决于版本和写法。

• Enterprise / Developer 版本：可能自动匹配，但前提是查询谓词覆盖索引列、统计信息准确、无参数嗅探偏差
• Standard / Express 版本：必须显式加 WITH (NOEXPAND) 提示，例如：SELECT * FROM dbo.vw_SalesSummary WITH (NOEXPAND) WHERE ProductID = 123
• 即使加了 NOEXPAND，若 WHERE 条件列不在聚集索引键中，仍可能退化为扫描基表
• 执行计划里看到 Clustered Index Seek/Scan 对应的是视图索引，而不是 Table Scan 或 Hash Match Aggregate，才算真正命中

最容易被忽略的是 ARITHABORT 设置和 NOEXPAND 提示——前者让索引视图“存在但不可见”，后者让优化器“看见但不选”，两者叠加就等于白建。