WHERE条件中对索引列使用CONVERT或CAST会导致索引失效，执行计划退化为Table Scan或Index Scan；应将转换移至参数侧或改用范围查询，并优先使用FORCESEEK替代INDEX提示。
WHERE 条件里对索引列用 CONVERT 或 CAST 就会丢掉 Index Seek
只要在视图或嵌套查询的 WHERE 子句中对索引列做了 CONVERT、CAST、LEFT、SUBSTRING 等任意函数操作，SQL Server 就无法做 SARGable 判断，执行计划必然退化为 Table Scan 或 Index Scan。
典型错误写法：
WHERE CONVERT(VARCHAR(10), create_time, 120) = '2024-01-01'
哪怕 create_time 是 DATETIME 类型且有索引，这个写法也等价于“全表扫描后逐行转换再比对”。
- 正确做法是把转换移到参数侧：
WHERE create_time >= '2024-01-01' AND create_time - 如果参数是字符串类型（比如
@input VARCHAR(20)），先转成目标类型再比较：WHERE id = CONVERT(INT, @input)→ 改为WHERE id = @input_int（在应用层或存储过程中提前转换） - 视图定义里尤其要检查
SELECT列表是否含计算列（如YEAR(create_time)），这类字段一旦被外层查询用于JOIN或WHERE，同样破坏下推能力
WITH (INDEX=...) 在视图查询中基本无效，改用 FORCESEEK 更可靠
WITH (INDEX=IX_date) 这类提示不能写在视图定义里，只能加在外层查询上；但即使加了，SQL Server 也常忽略它——尤其当提示的索引不覆盖查询所需列（触发 Key Lookup）、或统计信息过期时。
更稳定的做法是用语义更强的提示：
SELECT * FROM my_view WITH (FORCESEEK)
它不依赖具体索引名，而是强制优化器选择 Seek 访问路径，对多索引场景兼容性更好。
- 若视图涉及多表
JOIN，提示只作用于紧邻的表别名：SELECT * FROM my_view t1 WITH (FORCESEEK) INNER JOIN other_table t2 ON ... -
FORCESEEK要求查询条件能匹配索引前导列，否则会报错Query processor could not produce a query plan because of the hints defined in this query - SQL Server 2016+ 支持
OPTION(FORCE ORDER)配合FORCESEEK控制连接顺序，但慎用：它可能让其他分支计划退化
嵌套视图 + 参数化查询时，OPTION(RECOMPILE) 比硬指定索引更治本
当视图被高频调用且参数取值分布极不均衡（例如 @status 99% 是 'A'，1% 是 'Z'），复用缓存计划会导致严重偏差——对 'A' 走索引，对 'Z' 却仍沿用同一计划引发慢查。
此时在外部查询加 OPTION(RECOMPILE)，比在视图里塞各种 HINT 更有效：
SELECT * FROM my_view WHERE status = @status OPTION(RECOMPILE)
- 它让每次执行都基于真实参数值生成新计划，真正实现“参数敏感”优化
- 代价是编译开销，对毫秒级小查询可能得不偿失；可先查
sys.dm_exec_query_stats中该语句的plan_generation_num是否频繁变化，确认是否真存在计划抖动 - 不要在视图定义里加
OPTION，SQL Server 不允许；必须加在外层SELECT末尾
MySQL 的 FORCE INDEX 和 SQL Server 的 FORCESEEK 不是同一件事
MySQL 的 FORCE INDEX (idx_name) 是告诉优化器“只许用这个索引”，但它不保证访问方式是 ref/range，也不防 Key Lookup；而 SQL Server 的 FORCESEEK 是强制访问模式（Seek），不绑定具体索引名。
常见误判：
- 在 MySQL 中写
SELECT * FROM t FORCE INDEX (a_idx) WHERE b = 1，但b不在a_idx里 → 直接退化为全表扫描，FORCE INDEX失效 - 在 SQL Server 中对无合适索引的列用
FORCESEEK→ 报错而非静默降级 - 跨数据库迁移时，不能直接把 MySQL 的
FORCE INDEX照搬成 SQL Server 的WITH (INDEX=...)，语义和容错逻辑完全不同
最易被忽略的一点：索引下推失效往往藏在视图底层，而不是你写的那条 SELECT。查执行计划时，必须展开到“实际执行的每个表”，确认每一层嵌套是否都走了 Seek。
