sp_cursoropen选择糟糕执行计划原因咨询：直接与游标执行性能差异

这种情况我在日常排查SQL Server性能问题时碰到过好多次，咱们一步步拆解这个问题的根本原因，顺便给你一些比索引提示更彻底的解决思路：

这是SQL Server里最常见的「同一查询不同执行速度」的元凶。简单来说：

• 当你在SSMS里直接执行字面量查询（比如WHERE id = 123）时，SQL Server会拿到这个具体的参数值，结合表的统计信息，生成针对这个值的最优执行计划（比如选择索引查找还是全表扫描）。
• 但当应用通过游标执行时，查询通常会被自动参数化（比如变成WHERE id = @p0），SQL Server会缓存这个参数化查询的执行计划。如果第一次执行游标时用的参数是「极端值」（比如返回1条数据的id），生成的计划是高效的索引查找；但后续用返回大量数据的参数时，SQL Server还是复用这个索引查找的计划，就会导致性能急剧下降——因为此时全表扫描反而更快，但计划已经被固定了。

• 游标通常是循环执行同一查询，参数不断变化，但SQL Server的计划缓存机制会默认复用之前的计划，不管当前参数是否适合。
• 部分游标类型（比如静态游标）会先把结果集加载到tempdb的临时表中，这额外的IO开销也会让糟糕的执行计划雪上加霜，但核心还是执行计划不匹配的问题。

DBCC FREEPROCCACHE确实会清空所有缓存的执行计划，但它只是「临时重置」：

• 清空后第一次执行游标时，SQL Server还是会基于当时的参数生成计划，如果这次的参数依然是极端值，后续复用计划时问题还会重现。
• 而且这个命令会清空所有计划，可能影响其他正常查询的性能，不适合作为长期解决方案。

• 强制每次执行重新编译：在游标内的查询末尾加上OPTION (RECOMPILE)，让SQL Server每次执行都根据当前参数生成最优计划。适合参数值分布差异极大的场景，缺点是每次编译会有一点点开销，但总比慢查询好。
• 指定优化方向：用OPTION (OPTIMIZE FOR (@param UNKNOWN))，让SQL Server基于表的整体统计信息生成计划，而不是「嗅探」第一次执行的参数。这样生成的计划是通用型的，不会被极端值带偏。
• 更新统计信息：执行UPDATE STATISTICS 你的表名 WITH FULLSCAN，确保SQL Server拿到最新的数据分布情况——如果统计信息过时，哪怕没有参数嗅探，也可能生成糟糕的计划。
• 换更轻量的游标类型：如果业务允许，把游标改成FAST_FORWARD（快速只进游标），它的开销远小于静态游标，而且SQL Server对这种游标的执行计划优化更友好。

内容的提问来源于stack exchange，提问作者Heinzi