视图展开后WHERE条件不满足最左前缀原则会导致索引失效；应确保过滤列从复合索引最左列连续使用，避免函数操作索引列，否则触发全表扫描。
视图展开后 WHERE 条件不满足最左前缀原则
视图本身不存数据，执行时会被优化器“内联展开”成基表的原始 SQL。如果视图定义里写了 WHERE b = ? AND c = ?，而基表上只有复合索引 INDEX(a, b, c)，那这个查询就完全跳过了最左列 a，索引直接失效——不是视图的问题，是展开后的语句没命中索引规则。
常见表现：执行计划里出现 Table Scan 或 Index Scan（非 Seek），哪怕你确认字段上有索引。
- 检查视图定义中所有过滤、JOIN、ORDER BY 涉及的列，是否严格从复合索引最左列开始连续使用
- 若高频查询只用
b和c，但现有索引是(a, b, c)，应新建(b, c)或调整为(b, c, a)（按查询频率和选择性排序） - 注意：
WHERE a = 1 AND c = 3这种“跳过中间列”的写法，只能用上a，c不参与索引查找，仍属部分失效
视图里对索引列做了函数或表达式操作
哪怕只加了个看似无害的 UPPER() 或 DATE()，也会让对应列的索引失效。比如视图里写 WHERE DATE(create_time) = '2025-09-01'，即使 create_time 有索引，也触发全表扫描。
这类问题在视图中特别隐蔽，因为开发时只看视图逻辑，容易忽略底层基表索引约束。
- 把函数操作移到右侧：改
DATE(create_time) = '2025-09-01'为create_time >= '2025-09-01' AND create_time - 避免在视图定义中对任何可能被外部 WHERE 过滤的列做计算，包括
ISNULL(col, default)、col + 1等 - 如必须做转换，考虑在基表上建计算列 + 索引，而非在视图里现场算
外部查询参数导致优化器误判索引选择性
当视图被带参数调用（如 SELECT * FROM v_orders WHERE order_id = @id），SQL Server 可能因参数嗅探（parameter sniffing）基于首次编译值生成执行计划。如果首次传的是低选择性值（如 @id = 0），优化器可能判定走索引不划算，后续即使传高选择性值（如真实订单ID），仍复用全表扫描计划。
这不是索引或视图写错了，而是执行计划缓存机制带来的副作用。
- 临时解决：加
OPTION (RECOMPILE)强制每次重编译（适合低频查询） - 长期方案：用局部变量绕过参数嗅探，例如
DECLARE @local_id = @id; WHERE order_id = @local_id - 检查实际执行计划里的“Parameter Compiled Value”和“Runtime Parameter Values”，确认是否偏差过大
统计信息陈旧或未启用 ANSI_NULLS/QUOTED_IDENTIFIER
视图要稳定走索引，依赖优化器对数据分布的准确判断。如果基表统计信息长期没更新（比如大表 INSERT 后没手动 UPDATE STATISTICS），优化器可能误估行数，主动放弃索引。
更隐蔽的是：如果你打算给视图加唯一聚集索引（即索引视图），却忘了在创建前执行 SET ANSI_NULLS ON; SET QUOTED_IDENTIFIER ON;，会直接报错 Msg 1934，连创建都失败。
- 定期运行
UPDATE STATISTICS dbo.YourTable WITH FULLSCAN（尤其在大批量 DML 后） - 索引视图必须前置设置 6 个会话选项，缺一不可；普通视图虽不强制，但建议统一开启以保持行为一致
-
QUOTED_IDENTIFIER OFF会导致视图定义无法被正确解析，间接影响索引决策
视图不走索引这件事，真正卡住人的往往不是语法对错，而是“以为自己在操作视图，其实是在调试一堆被展开、被重写、被缓存的基表 SQL”。盯住执行计划里那个真实的 SELECT 片段，比反复检查视图定义有用得多。
