索引视图仅在满足严格条件（如WITH SCHEMABINDING、确定性定义、COUNT_BIG(*)、唯一聚集索引等）且查询模式稳定时才适合替代汇总表；否则会拖慢DML性能、增加维护成本，并可能被优化器忽略。
索引视图（Indexed View）在 SQL Server 2019 中不是“替代汇总表”的万能开关，而是**仅当满足严格条件且查询模式高度稳定时，才值得用它替代手工维护的汇总中间表**。盲目创建索引视图反而会拖慢写入、增加维护成本，甚至被查询优化器直接忽略。
为什么索引视图常被误用？
很多人看到“索引视图能物化聚合结果”，就以为它和 CREATE TABLE AS SELECT ... GROUP BY 的汇总表一样好用。但关键区别在于：索引视图是数据库引擎强制维护的物理结构，所有底层基表的 INSERT/UPDATE/DELETE 都要同步更新它的索引页——这会显著拖慢 OLTP 写入性能。
- 常见错误现象：
SELECT * FROM MyIndexedView执行很快，但业务系统里某张订单表的INSERT延迟从 5ms 涨到 80ms，DBA 才发现是索引视图在背后做维护 - 触发条件：只要基表有任意 DML，SQL Server 就必须保证索引视图数据一致性，无法跳过
- 兼容性影响：索引视图要求基表必须带
Schemabinding，意味着你不能随意ALTER TABLE列名或删列，否则整个视图失效
创建索引视图前必须检查的硬性条件
SQL Server 2019 不会自动帮你校验这些，漏一条就会导致 CREATE UNIQUE CLUSTERED INDEX 失败，或后续查询完全不走该索引视图。
-
CREATE VIEW必须带WITH SCHEMABINDING，且所有引用对象（表、函数）都需在同一数据库中 - 视图定义中不能出现：
GETDATE()、NEWID()、子查询（除非在WHERE或HAVING中）、TOP、UNION、NOT IN、LIKE带通配符开头等非确定性表达式 - 聚合必须包含基表的
COUNT_BIG(*)（不是COUNT(*)），否则无法创建唯一聚集索引 - 聚集索引键必须是视图中所有参与分组的列，且类型不能为
text/ntext/image/xml
如何确认查询真正在用索引视图？
即使你成功建好了索引视图，SQL Server 优化器默认也不会自动“重写”你的查询去匹配它。必须显式启用或满足特定条件。
- 最可靠方式：在查询中直接
FROM索引视图，并确保SET NOCOUNT OFF和ANSI_NULLS ON已启用（SSMS 默认满足） - 想让普通查询自动命中：需开启
SET QUERY_OPTIMIZER_HOTFIXES ON并使用OPTION (EXPAND VIEWS)——但 SQL Server 2019 默认不启用自动匹配，别指望它像 MySQL 的物化视图那样透明 - 验证是否命中：查看执行计划，聚集索引扫描对象名要是你的视图名（如
MySalesSummary），而不是基表；若看到Compute Scalar+Hash Match，说明还是在运行时算，没走物化结果
比索引视图更实用的替代方案
对大多数业务场景，“汇总中间表 + 定时刷新”仍是更可控、更低风险的选择。SQL Server 2019 提供了更轻量的手段来逼近物化效果：
- 用
sp_refreshview配合作业，在低峰期手动刷新视图元数据（适用于只读报表库） - 把汇总逻辑封装进带
SCHEMABINDING的内联表值函数（ITVF），配合查询提示OPTION (RECOMPILE)让优化器更好估算行数 - 对高频小范围聚合（如按天统计），优先考虑
columnstore index+GROUP BY查询，SQL Server 2019 的批处理模式能加速 5–10 倍，还不锁表
真正容易被忽略的一点：索引视图的存储开销和基表几乎一样大，而且一旦创建，就无法在线重建其聚集索引——维护窗口期可能比你预估的长得多。
