创建索引视图前必须满足：ANSI_NULLS和QUOTED_IDENTIFIER为ON；视图定义不含非确定性函数、子查询、TOP等；聚合必须含COUNT_BIG(*)；基表名用两段式。
SQL Server 里创建索引视图前必须满足哪些条件
索引视图不是所有查询都能套用，SQL Server 对它有一套硬性约束，不满足就建不了唯一聚集索引，也就谈不上加速。最常卡住的地方是 SET 选项和视图定义本身。
-
ANSI_NULLS、QUOTED_IDENTIFIER必须为 ON（连接级和创建时都得开） - 视图不能含
GETDATE()、NEWID()、子查询、TOP、UNION、OUTER JOIN、NOT IN等非确定性或复杂结构 - 聚合必须包含
COUNT_BIG(*)（哪怕你只想要COUNT(*)），否则无法建唯一聚集索引 - 基表名必须用两段式写法（如
dbo.Sales），不能用别名或三段式
如何写一个能被索引的聚合视图
核心是让 SQL Server 能把聚合结果固化成物理存储。关键动作是：先建视图，再加 WITH SCHEMABINDING，最后在视图上建唯一聚集索引。
CREATE VIEW dbo.v_SalesSummary
WITH SCHEMABINDING
AS
SELECT
ProductID,
SUM(Quantity) AS TotalQty,
COUNT_BIG(*) AS RowCnt -- 必须有，不可省略
FROM dbo.Sales
GROUP BY ProductID;接着执行：
CREATE UNIQUE CLUSTERED INDEX IX_v_SalesSummary_ProductID ON dbo.v_SalesSummary (ProductID);
注意：ProductID 必须是 GROUP BY 中的列，且整个组合要能唯一标识每行——否则建索引会失败。
为什么查询没走索引视图，反而变慢了
即使视图建好了，SQL Server 默认也不一定用它。常见原因有：
- 查询中用了视图未包含的列（比如你只聚合了
ProductID和SUM(Quantity)，但 SELECT 加了ProductName，就会回表甚至弃用视图） - 没加
NOEXPAND提示，尤其在复杂 JOIN 或嵌套查询中，优化器可能选择展开视图而不是读索引 - 基表统计信息过期，导致优化器误判成本；执行
UPDATE STATISTICS到视图或基表可缓解 - 数据库兼容级别低于 90（SQL Server 2005），索引视图会被忽略
强制走视图的写法：
SELECT ProductID, TotalQty FROM dbo.v_SalesSummary WITH (NOEXPAND);
索引视图对写入性能的影响不能忽视
视图索引是物理结构，每次 INSERT/UPDATE/DELETE 基表数据，SQL Server 都要同步更新这个索引。这意味着：
- 写操作延迟上升，尤其高并发插入场景下，可能成为瓶颈
- 如果基表本身更新频繁、聚合维度又很细（比如按秒分组），维护成本远高于收益
- 索引视图占用额外磁盘空间，且不会自动压缩；
DATA_COMPRESSION可以加在索引上，但需显式指定
真正适合的场景是：读远多于写、聚合逻辑稳定、结果集相对静态（比如日结报表、BI 层宽表）。临时性或高度动态的聚合，不如用物化 CTE 或定期刷新的持久化表。
