SQL Server中视图内计算列无法自动优化谓词过滤，真正有效的是在基表创建PERSISTED计算列并建索引；因视图仅是查询封装，不存储数据，YEAR(OrderDate)等表达式每次执行仍实时计算且不可索引，导致WHERE条件无法下推、全表扫描。
直接说结论：SQL Server 中「计算列 + 视图」本身不自动优化谓词过滤，真正起效的是在基表上创建 PERSISTED 计算列并为其建索引，再让视图引用该列——否则视图里写个 YEAR(OrderDate) 这类表达式，照样无法走索引。
为什么视图里加计算逻辑通常没用？
SQL Server 视图只是 SELECT 的封装，不存储数据，也不预计算。你在视图定义里写 YEAR(OrderDate) AS OrderYear，每次查询仍会实时计算每一行，且该列默认不可索引。优化器看到外层 WHERE OrderYear = 2024，无法下推到扫描阶段，最终还是全表扫+计算。
常见错误现象：
- 视图定义含
DATEPART(YEAR, OrderDate)或ISNULL(Status, 'Unknown')，但执行计划显示 Clustered Index Scan - 外部查询加了
WHERE OrderYear = 2024，却没触发 Seek，IO 次数和全表查一样 - 误以为“视图里提前算好，就能快”，结果发现比直接查基表还慢（因多了列投影和隐式转换）
真正有效的做法：基表加 PERSISTED 计算列 + 索引
必须把计算逻辑落到基表，并标记为 PERSISTED，这样 SQL Server 才允许在它上面建索引。视图只需简单 SELECT 这个已索引的列即可享受谓词下推。
实操步骤：
- 在基表添加计算列：
ALTER TABLE Orders ADD OrderYear AS YEAR(OrderDate) PERSISTED - 立即建索引：
CREATE INDEX IX_Orders_OrderYear ON Orders(OrderYear) - 视图定义保持简洁：
CREATE VIEW v_OrdersByYear AS SELECT ID, OrderDate, OrderYear FROM Orders - 查询时 WHERE 直接用该列：
SELECT * FROM v_OrdersByYear WHERE OrderYear = 2024—— 执行计划将出现 Index Seek
注意：非 PERSISTED 的计算列不能建索引；PERSISTED 列会占用磁盘空间，但换来的是可预测的 Seek 性能。
哪些计算逻辑适合走这条路？
适合的场景需同时满足：确定性（deterministic）、精度可控、业务高频过滤。不是所有表达式都行。
推荐用法：
- 日期截断：
YEAR(OrderDate)、DATEFROMPARTS(YEAR(OrderDate), MONTH(OrderDate), 1) - 状态归类：
CASE WHEN Status IN ('A','B') THEN 'Active' ELSE 'Inactive' END（需确保 deterministic） - 字符串前缀：
LEFT(Email, CHARINDEX('@', Email) - 1)（但要注意 NULL 和 @ 缺失情况）
明确避免：
- 调用非确定性函数：
GETDATE()、NEWID()、RAND() - 涉及用户自定义函数（UDF），除非显式标记为
DETERMINISTIC且无副作用 - 大字段计算，如
CONVERT(VARCHAR(MAX), JSON_QUERY(Data, '$.tags'))—— 索引建不起来，还拖慢 INSERT/UPDATE
谓词下推是否真发生？怎么验证？
不能只看视图定义或执行时间，得看实际执行计划里「谓词」出现在哪一层。
验证方法：
- 对视图查询开启实际执行计划（
CTRL+M），右键聚集索引或非聚集索引操作符 → 「属性」→ 查看Seek Predicates是否包含OrderYear = 2024 - 若只在
Residual Predicate里看到该条件，说明没下推成功，仍是先 Seek 大量数据再 Filter - 对比基表直接查：
SELECT * FROM Orders WHERE YEAR(OrderDate) = 2024，执行计划大概率是 Scan + Compute Scalar，性能差距一目了然
最容易被忽略的一点：即使你建了 PERSISTED 列和索引，如果查询中用了 WHERE OrderYear = CAST(@year AS VARCHAR)，类型不匹配仍会导致索引失效——务必保证参数类型与计算列类型完全一致。
