视图查询不走索引的根本原因是视图本身不存储数据，仅保存SELECT语句，优化器会将其展开为基表查询，若展开后的SQL无法匹配基表索引（如函数操作、复合索引顺序不当等），则导致索引失效。
视图查询不走索引，根本原因是什么
视图本身不存数据，只是保存的 SELECT 语句。SQL Server 查询优化器在执行 SELECT * FROM vw_xxx 时，会把视图展开成底层表的原始查询，再基于基表结构和统计信息生成执行计划。所以「视图没用上索引」，99% 是因为展开后的实际 SQL 没命中基表上的索引，而不是视图“坏了”。
常见现象包括：执行计划里出现 Table Scan 或 Clustered Index Scan，而你明明给 WHERE 条件列建了索引；或者 JOIN 后大量 Sort / Hash Match，说明连接列或筛选列缺乏有效索引。
让视图查询用上索引的关键动作
不是给视图加索引（普通视图不能加），而是确保它展开后能触发基表索引。核心操作有：
- 检查视图中所有
WHERE、JOIN ON、ORDER BY涉及的列，是否在对应基表上有合适索引——尤其注意复合索引的列顺序是否符合最左前缀原则 - 避免在视图定义里对索引列做函数操作，比如
WHERE YEAR(OrderDate) = 2025会让OrderDate上的索引失效；应改写为WHERE OrderDate >= '2025-01-01' AND OrderDate - 视图里别用
SELECT *，只选真正需要的列；如果外部查询只取 3 列，但视图定义拉了 20 列，可能影响覆盖索引判断 - 确认基表统计信息是更新的：
UPDATE STATISTICS dbo.Orders WITH FULLSCAN，否则优化器可能误判选择性而放弃索引
什么时候该考虑索引视图（物化视图）
只有当视图满足严格前提，且读远多于写时，才值得上 WITH SCHEMABINDING + 唯一聚集索引。典型适用场景：
- 聚合类视图，如
GROUP BY ProductID+COUNT_BIG(*)+SUM(Amount) - 频繁被多个查询 JOIN 或 WHERE 过滤，且结果集稳定、变化不频繁
- 基表 DML 不频繁（
INSERT/UPDATE/DELETE会同步维护索引视图，开销明显）
必须前置设置：SET ANSI_NULLS ON; SET QUOTED_IDENTIFIER ON; 等 6 项会话选项，且视图创建必须带 WITH SCHEMABINDING，否则 CREATE UNIQUE CLUSTERED INDEX 会直接报错 Msg 1934。
容易被忽略的坑：参数嗅探与视图嵌套
如果视图被另一个视图引用（嵌套），或外部查询带参数（如 WHERE ProductID = @pid），优化器可能因参数值不同生成不同计划，导致某次执行走了索引、另一次全表扫描。这不是视图问题，而是参数嗅探现象。
临时缓解可加查询提示：OPTION (RECOMPILE)；长期方案是检查参数类型是否匹配（比如 @pid 是 INT，但基表列是 BIGINT 就会隐式转换），或拆出关键过滤逻辑到 CTE 中显式控制执行路径。
索引视图的维护成本常被低估——它让写操作变慢，且一旦涉及的基表结构变更（如删列、改类型），所有依赖它的索引视图都会失效，必须重建。上线前务必在真实负载下压测 DML 性能。
