计算列和过滤索引仅在查询条件精确匹配时提升性能；计算列须persisted并更新统计信息，过滤索引需严格匹配where条件，二者组合对写法敏感且增加写入开销。
计算列和局部索引本身不能直接“提升查询速度”，除非它们被真正用在查询条件或覆盖路径中；盲目添加反而增加维护开销、拖慢写入，甚至让优化器选错执行计划。
计算列没走索引？检查是否持久化且有统计信息
SQL Server 中的计算列默认不存储物理值，WHERE 条件里引用它时无法利用索引——除非显式声明为 PERSISTED 并建索引。
- 非持久化计算列（如
ALTER TABLE orders ADD full_name AS first_name + ' ' + last_name）无法建索引，查询中写WHERE full_name = 'Alice Smith'会强制全表扫描 - 必须加上
PERSISTED：ALTER TABLE orders ADD full_name AS first_name + ' ' + last_name PERSISTED - 建索引前要确保统计信息已更新：
UPDATE STATISTICS orders WITH FULLSCAN，否则优化器可能低估选择性而弃用该索引 - 若计算逻辑含不确定函数（如
GETDATE()、NEWID()），则无法标记为PERSISTED，这类列天然不适合索引
局部索引不是 SQL Server 的原生概念：你可能想说的是过滤索引
SQL Server 没有“局部索引”这个术语，但常被误指为 FILTERED INDEX。它只索引满足条件的行子集，空间小、维护快、命中率高，但使用场景非常具体。
- 典型适用场景：状态字段中只有少量活跃数据，比如
WHERE status IN ('processing', 'pending')，占全表不到 5%，可建CREATE INDEX IX_orders_active ON orders (order_id, created_at) WHERE status IN ('processing', 'pending') - 查询必须严格匹配
WHERE子句条件才能用上该索引；写成WHERE status = 'processing' AND user_id > 1000可以，但WHERE status != 'done'就不行 - 过滤表达式不能含参数（如
@status），也不能含函数调用（如WHERE YEAR(created_at) = 2024），否则索引失效 - 注意：过滤索引不包含被过滤掉的行，所以
SELECT COUNT(*)或未带过滤条件的查询不会用它
计算列 + 过滤索引组合使用时的坑
两者叠加看似强大，实则对查询写法极其敏感；稍有偏差，整个优化就归零。
- 假设建了持久化计算列
is_high_value AS CASE WHEN amount > 10000 THEN 1 ELSE 0 END PERSISTED，再建过滤索引WHERE is_high_value = 1 - 查询必须写成
WHERE is_high_value = 1，不能写成WHERE amount > 10000——即使逻辑等价，优化器也不会自动重写，索引不会被选中 - 如果存储过程中用变量传参，比如
WHERE is_high_value = @flag，而@flag是BIT类型，SQL Server 可能因参数嗅探导致计划缓存复用失败，反而比直接查amount更慢 - 这种组合会让执行计划更难调试：
SET STATISTICS XML ON后看计划，要确认Index Seek节点的Predicate是否精确匹配过滤条件，而不是退化为Index Scan
最易被忽略的一点：计算列和过滤索引都会增加 INSERT/UPDATE 的 CPU 开销，尤其当表写入频繁时，性能收益可能被抵消。上线前务必在生产级数据量和并发压力下实测写入延迟变化。
