我有一个以前工作正常的存储过程。得到结果需要4到5秒。
过去两个月我没有使用过这个存储过程。当我现在调用相同的程序时，产生结果需要5分钟以上。 （过去两个月我的源表中没有填充记录）
我转换了存储过程并作为TSQL块执行它恢复正常。但是当我再次转换回存储过程时，它需要超过5分钟。
我想知道它为什么会这样。我使用了6个表变量。我只是填充这些表变量，通过加入所有这些来获得所需的结果。
我已经尝试过以下选项
With Recompile at the stored procedure level
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
sp_updatestats
但没有改善。当我作为TSQL执行它时它工作正常。
请建议我优化存储过程的任何想法。
答案 0 :(得分：3)
在您的查询中，添加OPTION(OPTIMIZE FOR UNKNOWN)（作为最后一个子句）以防止参数嗅探。有关语法和说明，请参阅Query Hints上的文档。
SQL Server第一次运行存储过程时所执行的操作是优化传递给它的参数的执行计划。这是在称为Parameter Sniffing的过程中完成的。
通常，执行计划由SQL Server缓存，因此SQL Server不必每次都为同一查询重新编译。下次运行该过程时，SQL Server将重新使用其中的查询的执行计划...但是，如果使用不同的参数调用它们（它们），执行计划可能完全没有效率
我给你的选项会告诉SQL编译器，执行计划不应该针对特定的参数进行优化，而是针对传递给的任何参数。存储过程。
引用文档：
未知的优化
指示查询优化器在编译和优化查询时使用统计数据而不是所有局部变量的初始值，包括使用强制参数化创建的参数。
在某些情况下，存储过程可以从参数嗅探中受益，在某些情况下它们不会。对于不受Paramater Sniffing影响的存储过程，您可以为使用存储过程的任何参数的每个查询添加该选项。
答案 1 :(得分：0)
您可能有与该proc关联的错误执行计划。 试试这个
DBCC FREESYSTEMCACHE ('ALL') WITH MARK_IN_USE_FOR_REMOVAL;
您可能还会发现这个有趣的内容 http://www.sqlpointers.com/2006/11/parameter-sniffing-stored-procedures.html