结论：在基础表上建普通汇总索引对视图聚合无效，仅索引视图（带唯一聚集索引且满足严苛前提）才能物化聚合结果并加速查询。
直接说结论：在基础表上建汇总索引对视图里的聚合运算基本无效，除非该视图是索引视图（即带唯一聚集索引的视图）。
为什么普通索引对视图聚合没用
SQL Server 的查询优化器不会自动把 SELECT SUM(sales), COUNT(*) FROM orders GROUP BY region 这类聚合语句“下推”到基础表的普通非聚集索引上——哪怕你给 orders(region, sales) 建了组合索引。因为普通索引只存键值+指针，不含预计算结果；而聚合需要扫描、分组、累加，必须访问实际数据行或至少是包含所需列的宽索引（覆盖索引）。
常见错误现象：SET STATISTICS IO ON 显示逻辑读很高，执行计划里仍是“聚集索引扫描”或“索引扫描 + Hash Match Aggregate”，没走预期的窄索引。
- 普通非聚集索引无法避免聚合所需的行遍历或哈希构建
- 即使索引包含所有 GROUP BY 和聚合列（如
region, sales），SQL Server 仍可能不选它——尤其当统计信息不准或估算行数偏大时 - 视图本身只是封装 SELECT，不改变底层执行逻辑；优化器看到的是展开后的语句，不是“视图名”
真正起效的方式：创建索引视图（Indexed View）
只有显式给视图加上 UNIQUE CLUSTERED INDEX，SQL Server 才会物化（持久化存储）聚合结果，后续查询才能直读这个“虚拟表”。这是唯一能让视图聚合变快的机制。
实操前提（缺一不可）：
- 视图必须用
WITH SCHEMABINDING创建（绑定基表结构，防止列被删/改） - 会话级 SET 选项要严格满足要求：
ANSI_NULLS=ON,QUOTED_IDENTIFIER=ON,ANSI_WARNINGS=ON,ARITHABORT=ON,CONCAT_NULL_YIELDS_NULL=ON,NUMERIC_ROUNDABORT=OFF - 聚合函数必须是确定性的（
SUM,COUNT_BIG,AVG等可用；GETDATE()或用户自定义非确定函数不行） - 不能含
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>
容易踩的坑：你以为建了索引就生效？其实未必
即使成功创建了索引视图，查询也不一定用它。优化器是否“自动匹配”取决于多个隐性条件：
- 查询中引用的列必须完全落在索引视图定义范围内；多查一个列（比如加
city）就会导致回退到基础表 - 如果查询带了
OPTION (EXPAND VIEWS)，强制禁用索引视图 - 基础表的统计信息过期，或视图自身统计未更新（
UPDATE STATISTICS不自动更新索引视图统计） - 数据库兼容级别低于 80（SQL Server 2000+ 要求），或
READ_COMMITTED_SNAPSHOT开启时某些场景受限 - 视图定义里用了
ISNULL、CASE等表达式，需确保其确定性；CONVERT类型转换若隐式失败也会拒用
验证是否真用了索引视图：看执行计划里是否有 Clustered Index Seek 或 Scan 指向 vw_SalesByRegion，而不是 orders；或者用 DBCC SHOW_STATISTICS ('vw_SalesByRegion', 'IX_vw_SalesByRegion_region') 查统计信息是否被命中。
最常被忽略的一点：索引视图的维护成本是实时的。每次对 orders 表做 INSERT/UPDATE/DELETE，SQL Server 都要同步更新 vw_SalesByRegion 的物化结果——这会拖慢写操作，且锁粒度可能变大。别只盯着读性能提升，忘了写路径的代价。
