SQL Server 同参数下内联执行与存储过程执行的意外性能差异咨询

核心常见差异原因（非服务器全局配置类） #

• 最普遍的触发因素是参数嗅探问题：手动在查询窗口执行时，优化器可以直接感知你定义的变量常量值，生成完全适配当前参数的执行计划；而存储过程执行时，会优先复用首次编译时基于其他参数值生成的缓存执行计划，一旦历史参数对应的数据分布和当前参数差异极大，就会出现计划和实际查询需求严重不匹配的情况，直接放大耗时。你提到的存储过程中存在JOIN嵌套SELECT的写法，本身逻辑语法没有问题，但这类多分支的嵌套结构一旦被错误计划选型影响，耗时差会比平铺写法更显著。
• 会话执行上下文的隐式设置差异：你手动打开的SSMS查询窗口，默认会携带一套固定的会话级配置（比如默认开启ARITHABORT），而存储过程被调用时，继承的是调用方的会话配置，只要两边存在哪怕一个影响优化器决策的设置不一致，就会生成完全独立的执行计划，不会互相复用。
• 执行时的参数解析路径差异：手动执行时你在窗口顶部定义的局部变量，会被优化器直接当作已知常量做行估算；但存储过程的入参在编译阶段，如果没有触发参数嗅探，优化器会将其视为数据平均分布的未知值，基于全局平均统计信息生成计划，这种估算偏差经常会导致选择效率极低的连接顺序或算子。

需要排查的服务器/数据库级设置 #

• 检查服务器与数据库层面的ARITHABORT默认配置：如果该值被设为OFF，所有存储过程调用的计划都会和SSMS手动窗口（默认ON）的计划分属不同的缓存分区，根本无法复用手动执行时生成的高效计划，这是同类问题最高发的配置原因。
• 检查数据库的参数化策略：如果开启了强制参数化，存储过程的查询会被强制做参数模板匹配，很容易命中其他相似SQL生成的低效率计划，和你手动执行时生成的专属计划出现差异。
• 检查数据库兼容级别与基数估算模型配置：如果数据库兼容级别较低，会触发老旧的基数估算逻辑，而你手动执行时如果会话上下文使用了更高版本的估算模型，两者对数据量的估算可能出现数量级偏差，直接导致计划选型错误。
• 检查计划缓存的资源约束：如果服务器内存压力较大，执行计划会被频繁回收，存储过程每次重新编译时，可能因为统计信息滞后、估算偏差生成和手动执行时完全不同的计划。

快速定位的实操方法：分别在调用存储过程和手动执行查询的场景下，开启SET STATISTICS IO, TIME ON并抓取实际执行计划，对比两个计划的算子选择、估算行数与实际行数的偏差，通常可以直接定位到计划选型的差异点。

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