架构绑定视图必须用WITH SCHEMABINDING创建，否则无法建索引；所有表名须两段式（如dbo.Table），禁用*、非确定性函数；建唯一聚集索引后才物化聚合结果，查询需严格匹配定义才能命中。
架构绑定视图必须用 WITH SCHEMABINDING 创建
不加 WITH SCHEMABINDING 的视图只是逻辑封装，SQL Server 无法保证底层表结构稳定，也就无法对它做任何物理优化。哪怕你后续在视图上建索引，也会直接报错：Cannot create index on view 'xxx' because the view is not schema bound.
创建时必须显式声明绑定，并且所有引用对象（表、函数）都要用两段式名称（schema.table），否则会失败。常见错误是漏写 dbo. 前缀，或引用了非确定性函数（如 GETDATE()、NEWID()），这些都会导致架构绑定失败。
- 必须用
CREATE VIEW dbo.v_SalesSummary WITH SCHEMABINDING AS SELECT ... - 视图中所有列名不能用
*，必须显式列出 - 不能引用临时表、表变量、TVF（除非是内联表值函数且确定性）
- 基表不能被 DROP 或 ALTER COLUMN（除非先 DROP 视图）
聚合视图上建唯一聚集索引才能触发物化
架构绑定只是前提，真正让聚合“变快”的关键动作是：在视图上创建唯一聚集索引（UNIQUE CLUSTERED INDEX）。只有这时，SQL Server 才会把聚合结果物理存储下来，后续查询直接读索引页，跳过实时 GROUP BY 和扫描。
注意：这个索引必须是 UNIQUE，而且键必须覆盖视图中所有用于分组的列（比如按 Year, ProductID 分组，索引键就得是这两列组合）。如果聚合结果可能重复（比如没加 DISTINCT 或分组列不全），SQL Server 会拒绝建索引。
- 索引键要包含所有 GROUP BY 列，顺序最好和视图定义一致
- SELECT 列里不能有 LOB 类型（
text,ntext,image,xml,varchar(max)等），否则无法建聚集索引 - 如果基表有大量写入，物化视图的维护开销会上升——每次 INSERT/UPDATE/DELETE 都要同步更新索引
查询必须“恰好匹配”视图定义才能重用物化结果
哪怕只多一个 WHERE 条件、少一个 GROUP BY 列，或者把 SUM(amount) 改成 ISNULL(SUM(amount), 0)，SQL Server 都不会自动重用已物化的索引。它不会“推导”等价性，只做字面匹配。
典型陷阱是应用层动态拼 SQL：视图定义是 GROUP BY Year, Month，但查询传参只过滤 Year = 2024，没带 Month —— 这种情况就无法命中物化索引，仍走实时聚合。
- 查询的 SELECT 列必须和视图完全一致（包括别名）
- WHERE 条件只能是视图 GROUP BY 列的等值过滤（
=），不能是范围（BETWEEN）、IN列表或表达式 - 不能加
ORDER BY，除非视图本身已含ORDER BY（但注意：视图里不允许ORDER BY，除非配合TOP） - 建议用
SET STATISTICS XML ON查看执行计划，确认是否出现Index Seek或Index Scan在视图索引上
物化视图不适合高写入频率的聚合场景
一旦在视图上建了唯一聚集索引，它就不再是“只读快照”，而是和基表强耦合的物化结构。每次修改基表数据，SQL Server 都要同步更新这个索引页——相当于给每个写操作额外加了一次索引维护成本。
实测中，当订单表每秒写入超 200 行时，带物化聚合视图的延迟明显上升；而换成内存优化表（Hekaton）+ 原生编译存储过程做实时聚合，反而更稳。所以不是所有聚合都适合物化，得看读写比。
- 读远大于写（比如日报表、BI 报表后台）——物化视图收益最大
- 写频繁且聚合维度多（如实时用户行为流）——优先考虑计算列 + 列存储索引，或迁移到 Hekaton 表
- SQL Server 2016+ 可用增量统计 + 自动更新机制缓解基数估计偏差，但对物化视图本身无影响
实际生效的关键点往往卡在最基础的地方：忘了 WITH SCHEMABINDING，或者建索引时漏了 UNIQUE，又或者以为“只要视图存在就能加速任意查询”。物化不是魔法，它是用存储换计算、用写开销换读性能的明确权衡。
