根本原因是SSMS与程序使用不同SET选项（如ARITHABORT默认值不同），导致SQL Server生成并缓存不同执行计划；其次为参数嗅探、动态拼接、统计信息陈旧及NUMA架构影响。
SSMS 和程序调用生成了不同执行计划
根本原因不是“SSMS 更快”，而是它和你的应用程序用了不同的 SET 选项，导致 SQL Server 认为这是两个完全不同的上下文，必须各自编译、各自缓存计划。最典型的是 ARITHABORT：SSMS 默认开启 SET ARITHABORT ON，而大多数 .NET 数据访问层（如 SqlCommand）默认是 OFF。
只要 set_options 值不同，哪怕只差一位，SQL Server 就不会复用计划——你看到的“快”，其实是 SSMS 每次都走了一条新编译出的高效路径；而程序则卡在某个低效旧计划里反复执行。
- 验证方法：查
sys.dm_exec_cached_plans+sys.dm_exec_plan_attributes，对比两者的set_options十进制值是否一致 - 快速确认：在 SSMS 中先执行
SET ARITHABORT OFF，再运行存储过程，看速度是否骤降 - 修复动作：在应用程序连接字符串中加
Packet Size=4096;Connection Timeout=30;ARITHABORT=True;（注意部分驱动需显式设置）
参数嗅探让首次参数决定后续所有性能
存储过程第一次被调用时，SQL Server 会“嗅探”传入的实际参数值，并基于该值生成执行计划。如果首次调用用了边缘参数（比如查空日期、极小 ID），优化器可能选索引查找；但后续业务调用主流参数（查整月数据），仍硬套这个计划，结果变成数万次嵌套循环+随机 I/O。
这种现象在程序中更明显，因为连接池复用连接，缓存计划长期驻留；而 SSMS 每次新开窗口或执行 DBCC FREEPROCCACHE 后，等于重来一次，反而容易撞上“好参数→好计划”的运气。
- 典型症状：
sys.dm_exec_query_stats中同一plan_handle的avg_logical_reads波动超过 5 倍 - 临时验证：在存储过程中关键查询后加
OPTION (RECOMPILE)，若变快，基本锁定参数嗅探 - 稳妥解法：把入参赋给局部变量再用于 WHERE，例如
DECLARE @local_id INT = @input_id;，切断直传嗅探链
动态拼接或 WITH RECOMPILE 让缓存形同虚设
你以为加了 WITH RECOMPILE 是“保险丝”，实际是主动关闭缓存开关。每次调用都从解析、绑定、优化到生成计划全走一遍，比即席查询还多一层元数据校验开销。更隐蔽的是 EXEC(@sql) 或 sp_executesql N'select...where id = ' + CAST(@id AS VARCHAR) 这类拼接——哪怕只拼一个值，SQL Server 也无法稳定哈希语句文本，导致无法命中缓存。
- 检查点：运行
SELECT usecounts, cacheobjtype, objtype FROM sys.dm_exec_cached_plans WHERE objtype = 'Proc'，如果目标存储过程的usecounts恒为 1，说明从未复用 - 替代方案：用
sp_executesql参数化（不是拼字符串！），例如sp_executesql N'SELECT * FROM t WHERE id = @id', N'@id INT', @id = @input_id - 警惕点：
OPTION (RECOMPILE)放在存储过程级（CREATE PROC ... WITH RECOMPILE）影响全局；放在单条语句后只影响该句，粒度更可控
统计信息陈旧或 NUMA 跨节点内存访问加剧差异
测试库数据少、更新频次低，统计信息准；生产库日增百万行，但 auto update statistics 阈值没触发（尤其大表），优化器仍按过期分布估算，选错索引甚至全表扫描。这在程序中暴露更彻底——SSMS 手动执行时可能碰巧触发了异步更新，而程序调用连续压测反而卡在旧计划里。
另外，生产服务器若为多路 CPU + NUMA 架构，SQL Server 实例未绑定节点，某次查询申请大内存时被迫跨节点分配，延迟陡增。这种硬件层抖动在 SSMS 单次交互中不易察觉，但在程序高并发调用下会被放大。
- 速查命令：
SELECT last_updated, rows, modification_counter FROM sys.dm_db_stats_properties(OBJECT_ID('YourTable'), 1) - NUMA 检查：
SELECT memory_node_id, pages_kb FROM sys.dm_os_memory_clerks WHERE type = 'MEMORYCLERK_SQLBUFFERPOOL'，观察是否集中在单个memory_node_id - 不要盲目
UPDATE STATISTICS ... FULLSCAN，大表慎用；优先考虑WITH SAMPLE 30 PERCENT或启用异步更新
真正卡住性能的，往往不是存储过程本身，而是你没意识到：计划缓存是个有状态的系统，它依赖参数一致性、SET 一致性、统计信息新鲜度和硬件拓扑稳定性。一旦其中一环松动，SSMS 和程序就自动走向两条执行路径。
