源博客地址 https://blog.csdn.net/pgbiao/article/details/22388945html
其余参考：参数探测(Parameter Sniffing)影响存储过程执行效率解决方案post
这篇文章对参数嗅探问题做了很详细的研究 https://www.cnblogs.com/lyhabc/articles/3222179.html测试
这两天遇到一个问题使人比较郁闷，一个大概120行左右的存储过程在SQL Server2012的查询分析器里面执行，
速度很是理想，1秒不到，便可筛选抓取到大概500条数据记录。
但在C#程序代码里调用，就提示链接超时。把CommandTimeout设置为300，就要3分钟左右时间才能显示出来，
检查了几遍代码也没有发现错误。问题依旧。
缘由分析：
一、因为在查询分析器里执行速度很快，而且数据量也很少。
二、只在程序里调用才有缓慢的状况。
三、设置CommandTimeout参数，就能够显示结果出来，但要好久。
综上分析，初步判定问题出在C#代码上。但检查后没有收获。
在百度上查询这方面的资料。
在CSDN论坛上终于找到相似的资料贴子。其中有一网友在回复中说“有多是执行计划过时吧”，
真是一言惊醒梦中的我。
当即在查询分析器上执行：url
exec sp_recompile @objname='存储过程名称'spa
再次测试程序，此次终于成功了。速度很满意。
缘由分析：
因为存储过程是预编译的, 在第一次执行的时候, 会生成执行计划, 之后执行的时候, 会使用这个执行计划(除非存储过程侯或者显示指定从新编译), 而不是每次执行时都去生成执行计划。
当存储过程涉及的对象结构调整, 或者相关的数据产生了很大变化, 这可能致使原来的计划不适合当前的现状(执行计划过时), 这种状况下应该从新编译存储过程。.net
若是修改一次不行，能够再修改一次，再等会测试htm