普通索引对视图聚合无效，仅索引视图（带唯一聚集索引且满足schemabinding、确定性函数、严格set选项等前提）才能物化聚合结果并加速查询。
普通视图加聚合函数本身不提升性能，只有创建索引视图（即带唯一聚集索引的视图）才能让聚合结果物化并加速查询。
为什么普通含聚合的视图查得慢
视图只是封装了 SELECT 语句，SQL Server 每次查询它都会展开成底层 SQL 并重新执行全量聚合。哪怕你在基础表上给 region 和 sales 建了组合索引，优化器仍大概率走 聚集索引扫描 或 Hash Match Aggregate——因为普通索引不存预计算值，无法跳过分组和累加过程。
-
SET STATISTICS IO ON显示逻辑读很高，说明仍在扫数据行 - 执行计划里看不到“索引查找”，只有“索引扫描”或“哈希匹配”节点
- 视图定义里用了
COUNT(*)，但基表没COUNT_BIG(*)—— 索引视图强制要求后者 - 会话的
ANSI_NULLS是OFF，导致后续建索引失败（错误信息：Cannot create index on view 'xxx' because the view is not schema bound）
创建索引视图的硬性前提
缺一不可，否则 CREATE UNIQUE CLUSTERED INDEX 会直接报错：
- 视图必须用
WITH SCHEMABINDING创建（绑定基表结构，防止列被删/改） - 所有引用的表名必须带两段式前缀，如
dbo.orders，不能是orders - 会话级设置必须全开：
ANSI_NULLS=ON、QUOTED_IDENTIFIER=ON、ANSI_WARNINGS=ON、ARITHABORT=ON、CONCAT_NULL_YIELDS_NULL=ON、NUMERIC_ROUNDABORT=OFF - 聚合函数必须确定性：可用
SUM、COUNT_BIG、AVG；禁用GETDATE()、NEWID()、用户自定义非确定函数 - 不能含
TOP、ORDER BY、COMPUTE、子查询中的聚合（除非在视图顶层）
实操步骤与最小可行代码
以下是最简能跑通的索引视图示例（注意字段顺序、函数选择、索引键）：
CREATE VIEW dbo.vw_SalesByRegion WITH SCHEMABINDING AS SELECT region, SUM(sales) AS total_sales, COUNT_BIG(*) AS cnt FROM dbo.orders GROUP BY region; GO <p>CREATE UNIQUE CLUSTERED INDEX IX_vw_SalesByRegion_region ON dbo.vw_SalesByRegion (region);</p>
-
COUNT_BIG(*)不是笔误——索引视图强制要求这个版本，COUNT(*)会报错 - 聚集索引必须建在
GROUP BY列上（这里是region），且必须是UNIQUE - 如果
region可能重复（比如有空值或业务允许同名不同区），需额外处理，例如加ISNULL(region, 'UNKNOWN')并确保唯一性 - 建完后，原查询
SELECT * FROM dbo.vw_SalesByRegion WHERE region = 'East'就会直读索引，逻辑读从几千降到个位数
容易被忽略的写法细节
即使满足全部前提，下面这些点仍会导致索引视图失效或无法使用：
- 外部查询用了
SELECT *但视图定义里漏了某列（比如忘了region），SQL Server 可能放弃使用索引视图 - 查询中加了
WHERE条件但字段不在视图定义的SELECT列表里，谓词无法下推，仍要扫全量物化结果 - 基表做了大批次
INSERT/UPDATE/DELETE，索引视图的物化数据会同步更新，写入开销变高——读多写少才适合 - 误以为“建了索引就自动生效”，其实必须保证查询时实际引用的是视图名（而非展开后的等价 SQL），且未开启
NOEXPAND提示时，某些版本可能不自动匹配
真正起效的不是“视图”本身，而是那个被持久化的、带唯一聚集索引的物化结果。只要基表结构或会话设置有一处不满足，它就退化回普通视图——而这个退化过程悄无声息，你只会在执行计划里发现它又开始扫全表了。
