索引视图通过物化存储GROUP BY聚合结果加速查询，但需满足SCHEMABINDING、COUNT_BIG(*)、同库两段式引用等硬性条件，且查询须字面匹配或显式使用NOEXPAND提示。
为什么 SQL Server 的索引视图能加速聚合查询
因为索引视图（Indexed View）在创建唯一聚集索引后，会物化存储计算结果，相当于把 GROUP BY + 聚合函数（如 SUM、COUNT、AVG）的结果提前算好并持久化到磁盘。后续查询只要满足引用条件，SQL Server 查询优化器就可能直接从该索引读取聚合值，跳过实时扫描和分组计算。
但注意：这不等于“自动生效”。必须满足严格前提，否则查询根本不会用上它。
创建索引视图前必须满足的硬性条件
- 视图必须使用
SCHEMABINDING 创建（绑定底层表结构，防止被意外修改）
- 所有引用的表和函数都必须在同一数据库中，且用两段式名称（如
dbo.Sales），不能用 *
- 聚合必须包含
COUNT_BIG(*)（不是 COUNT(*)），否则无法创建唯一聚集索引
- 若含
GROUP BY，必须包含所有非聚合列，并确保组合唯一；推荐加 WITH (SCHEMABINDING) 和显式 SELECT 列表
- 基础表需有主键或唯一约束（尤其当视图要建唯一聚集索引时）
SCHEMABINDING 创建（绑定底层表结构，防止被意外修改）dbo.Sales），不能用 *
COUNT_BIG(*)（不是 COUNT(*)），否则无法创建唯一聚集索引GROUP BY，必须包含所有非聚合列，并确保组合唯一；推荐加 WITH (SCHEMABINDING) 和显式 SELECT 列表示例关键片段：
CREATE VIEW dbo.v_SalesByRegion
WITH SCHEMABINDING
AS
SELECT
Region,
COUNT_BIG(*) AS cnt,
SUM(Amount) AS total_amt
FROM dbo.Sales
GROUP BY Region;之后才能执行：CREATE UNIQUE CLUSTERED INDEX IX_v_SalesByRegion ON dbo.v_SalesByRegion (Region);
查询时如何让优化器真正用上索引视图
默认情况下，SQL Server 仅在 SET ANSI_NULLS ON、SET QUOTED_IDENTIFIER ON 等会话设置开启时才考虑索引视图；更重要的是，查询写法必须“字面匹配”视图定义——不能多列、不能改别名、不能加额外谓词（除非是可推导的等值过滤）。
常见失效场景：
- 查询写成
SELECT Region, COUNT(*) FROM dbo.Sales GROUP BY Region→ 不会匹配视图（少COUNT_BIG，且没引用视图） - 查询写成
SELECT * FROM dbo.v_SalesByRegion WHERE Region = 'North'→ 可命中索引（前提是索引键是Region） - 查询写成
SELECT Region, total_amt FROM dbo.v_SalesByRegion→ 会走索引，但若加了ORDER BY total_amt，可能触发排序，削弱优势 - 跨库查询或用了
NOEXPAND提示以外的 hint，也可能绕过
强制使用（调试/确定场景下）：SELECT * FROM dbo.v_SalesByRegion WITH (NOEXPAND);
容易被忽略的维护与性能陷阱
索引视图不是“设完就不管”的加速器。它的代价是写入放大和存储开销：
- 每次对基础表
INSERT/UPDATE/DELETE，SQL Server 都要同步更新视图索引，可能显著拖慢写操作 - 若基础表有高并发写入，而聚合维度又很宽（比如按秒级时间戳分组），索引维护成本会急剧上升
-
NOEXPAND在某些版本（如 Standard Edition）下并非默认启用，企业版才支持自动匹配；开发环境测试时务必确认执行计划里是否真出现了视图索引的Clustered Index Seek - 视图定义变更需先删索引再改视图，且依赖关系检查严格——
ALTER VIEW不能用于带索引的视图，必须DROP INDEX+DROP VIEW+ 重建
最常被漏掉的一点：索引视图不支持 GETDATE()、NEWID() 等非确定性函数，也不能引用临时表或表变量。
