索引视图是提升复杂公式查询性能的关键，需满足确定性、架构绑定等条件并按三步创建；普通视图仅保存SQL语句，不预计算，无法加速含JOIN/GROUP BY/SUM/CASE的实时计算。
CREATE VIEW 是最直接的入口，但光建视图不等于性能提升——关键在于是否启用索引视图，以及公式本身是否满足可索引条件。
为什么普通视图对复杂公式没用？
普通视图只是“保存的 SELECT 语句”，每次查询都重跑整个逻辑。比如一个含 JOIN + GROUP BY + SUM + CASE 的销售毛利公式，每次调用都在实时计算，基表数据一多就卡顿。
它不存结果，也不走预计算，只省了写 SQL 的事，没省 CPU 和 I/O。
- 视图定义里不能有
TOP、ORDER BY、子查询（在 SELECT 列表中）、聚合函数嵌套（如SUM(AVG(x))） - 所有引用表必须用两段式名称（
schema.table），且加WITH SCHEMABINDING -
SELECT列不能是表达式别名重复、不能是*、不能含不确定函数（如GETDATE()、NEWID()）
哪些公式能走索引视图？
只有满足确定性、可持久化、无副作用的公式才允许创建聚集索引。典型可索引场景：
- 基于单表或少数关联表的聚合：如
COUNT_BIG(*)、SUM(Quantity)、AVG(UnitPrice) - 确定性计算列：如
UnitPrice * Quantity AS LineTotal（注意不是ROUND(UnitPrice * Quantity, 2)，因为ROUND在某些兼容级别下非确定性） - 带
GROUP BY的分组汇总，且分组键唯一可索引（如主键或唯一约束列）
反例：DATEDIFF(DAY, OrderDate, GETDATE()) 不行（GETDATE() 非确定性）；ISNULL(DiscountRate, 0) * TotalAmount 可以，但需确保 DiscountRate 列允许 NULL 且类型明确。
创建索引视图的三步实操
跳过语法检查直接执行会报错，必须严格按顺序来：
- 第一步：用
WITH SCHEMABINDING创建视图，所有表引用带 schema，聚合列用COUNT_BIG(*)（不是COUNT(*)） - 第二步：在视图上建唯一聚集索引，索引键必须包含所有
GROUP BY列，且不能为 NULL（可用ISNULL(GroupCol, -1)做兜底） - 第三步：确认查询真正命中索引视图——开
SET STATISTICS XML ON，看执行计划里是否出现Index Seek或Index Scan对应你的视图名，而不是基表
示例片段：
CREATE VIEW dbo.vw_OrderSummary WITH SCHEMABINDING AS SELECT o.ProductID, COUNT_BIG(*) AS OrderCount, SUM(od.Quantity) AS TotalQty, SUM(od.Quantity * od.UnitPrice) AS GrossRevenue FROM dbo.Orders o JOIN dbo.OrderDetails od ON o.OrderID = od.OrderID GROUP BY o.ProductID; GO <p>CREATE UNIQUE CLUSTERED INDEX IX_vw_OrderSummary ON dbo.vw_OrderSummary (ProductID);
容易被忽略的坑
索引视图不是“设了就有效”。SQL Server 默认不会自动重写查询去匹配视图，除非满足以下任一条件：
- 查询显式从视图取数：
SELECT * FROM dbo.vw_OrderSummary WHERE ProductID = 123 - 启用
QUERYRULES或设置SET NOEXPAND（强制使用视图索引，否则可能仍走基表） - 数据库兼容级别 ≥ 120（SQL Server 2014+），且查询结构与视图定义高度一致（列名、聚合方式、JOIN 顺序都不能偏差）
更隐蔽的问题：基表更新时，索引视图同步刷新会拖慢写操作；如果公式里用了 CONVERT 或隐式类型转换，可能导致索引失效——宁可用 CAST(col AS DECIMAL(18,2)) 显式声明，也别依赖自动推导。
