索引视图仅在满足严格条件时加速聚合查询：必须含count_big(*)、sum等聚合函数，group by列来自带唯一约束的单表，视图需schemabinding和唯一聚集索引，且查询须直接引用视图、列名与定义完全一致，否则仍实时计算。
索引视图能加速求和类统计，但必须满足硬性条件
直接结论：只有当视图定义中包含 COUNT_BIG(*)、SUM 等聚合函数，且基表主键或唯一约束被显式引用，同时外部查询严格匹配视图结构（列名、聚合逻辑、谓词下推）时，SQL Server 才会真正使用索引视图的物理存储来跳过实时计算。否则，它只是个普通视图，每次执行都重算。
常见失效现象：SELECT Region, SUM(Amount) FROM Sales GROUP BY Region 不会命中索引视图；SELECT * FROM v_SalesByRegion 会走索引，但若加了 ORDER BY SUM_Amt DESC，可能触发额外排序，抵消预聚合优势。
- 必须用
COUNT_BIG(*)替代COUNT(*)—— 这是 SQL Server 强制要求，否则无法创建唯一聚集索引 - 所有参与
GROUP BY的列，必须来自单个基表，且该表需有唯一约束（主键或唯一索引） - 视图中不能含
TOP、ROW_NUMBER()、子查询、非确定性函数（如GETDATE()） - 外部查询必须直接引用视图名，不能嵌套在 CTE 或子查询里，否则优化器大概率放弃使用
创建索引视图的最小可行脚本
以按区域汇总销售金额为例，假设 Sales 表有主键 SaleID，且 Region 是可分组维度：
CREATE VIEW dbo.v_SalesByRegion
WITH SCHEMABINDING
AS
SELECT
Region,
COUNT_BIG(*) AS cnt,
SUM(ISNULL(Amount, 0)) AS total_amt
FROM dbo.Sales
GROUP BY Region;
GO
<p>-- 必须先建唯一聚集索引，否则视图无法物化
CREATE UNIQUE CLUSTERED INDEX IX_v_SalesByRegion_Region
ON dbo.v_SalesByRegion (Region);
</p>
注意：WITH SCHEMABINDING 是强制的，它锁定基表结构，防止后续修改破坏视图一致性；ISNULL 是为了确保 SUM 输入确定，避免 NULL 导致聚合行为不可预测。
- 如果
Sales表没有主键，先加ALTER TABLE Sales ADD CONSTRAINT PK_Sales PRIMARY KEY (SaleID); - 若想支持多维分组（如 Region + Year），则
GROUP BY列必须联合唯一，或在视图中显式 JOIN 带唯一约束的时间维度表 - 不要在视图里用
SELECT *，哪怕基表只增列不删列，也会导致索引视图失效
查询时如何确保命中索引视图
即使视图建好了，90% 的 BI 查询仍会绕过它——因为没写对调用方式。核心原则：让优化器“一眼看出”你能用上预聚合结果。
- 必须直接查视图，且列名与定义完全一致：
SELECT Region, total_amt FROM dbo.v_SalesByRegion✅；SELECT Region, SUM_Amt FROM ...❌（别名不匹配） - WHERE 条件要落在索引键上：
WHERE Region = 'North'可走索引查找；WHERE total_amt > 10000会全扫视图，无法下推到基表过滤 - 避免在外部加
ORDER BY、HAVING、UNION—— 这些操作会迫使优化器放弃使用物化结果，转为展开视图重新执行 - 调试时可用
SELECT * FROM dbo.v_SalesByRegion WITH (NOEXPAND)强制使用，但生产环境应靠写法自然触发，而非依赖提示
容易被忽略的维护成本和适用边界
索引视图不是银弹。它的优势只在“读远大于写”的 BI 报表场景成立，一旦写入频繁，代价立刻显现。
- 每次向
Sales表插入/更新/删除一行，SQL Server 都要同步更新v_SalesByRegion的物化结果 —— 这比普通索引开销更大 - 视图占用额外磁盘空间，且
sp_spaceused查不到它的大小，得用sys.dm_db_partition_stats查object_id对应分区 - 如果业务要求“近实时”，而写入每分钟上千次，建议改用增量更新的汇总表 + 定时任务，而非索引视图
- 跨数据库查询、使用链接服务器、或在视图定义中引用其他库的表，索引视图直接不可用
