我们遇到了一个sp.的问题.
我们有一个非常简单的sp,包含一个声明的表和一些外部连接,最终返回20到100行之间.
由于查询这个sp在生产环境和测试环境中都表现不佳,所以我们最近重写了它,使其更加高效,并且在我们的测试环境中以卓越的性能进行了测试.
我们将其发布到生产中,只是为了发现它仍然很慢,导致我们的.NET 2.0应用程序在调用时超时.
我们什么也没有理解,并进入了Management Studio的生产数据库,并运行了sp,在1秒钟内执行.
也就是说,当从我们的应用程序运行时,它极其缓慢,导致超时,当从Management Studio运行时,它非常快速,从不需要更多的时间.
解决方法
我认为你的问题可能是“参数嗅探”.
sql Server的执行环境在编译或重新编译期间“嗅探”sp的参数值,以生成更快的执行计划,这是一个过程.但是有时它会获得一些参数的组合,这些参数与sp将返回的当前数据一起成为一个非常慢的sp.
sql Server的执行环境在编译或重新编译期间“嗅探”sp的参数值,以生成更快的执行计划,这是一个过程.但是有时它会获得一些参数的组合,这些参数与sp将返回的当前数据一起成为一个非常慢的sp.
那里有几个很好的解释.搜索Stackoverflow.
这是一个很好的：
http://omnibuzz-sql.blogspot.com/2006/11/parameter-sniffing-stored-procedures.html
一个可能的解决方案是在sp中创建局部变量,并将输入的参数值设置为它们.然后只使用sp中的局部变量.
CREATE PROCEDURE [dbo].spTest @FromDate as DATETIME AS BEGIN DECLARE @FromDate_local as DATETIME SET @FromDate_local = '2009-01-01' SET @FromDate_local = @FromDate ... SELECT * FROM TestTbl WHERE FromDate >= @FromDate_local END
