2015-12-16 42 views
5

我有一个查询正在放入存储过程。当我使用局部变量运行查询时,查询需要1秒钟才能运行。当我将相同的查询放入存储过程并调用SP时,大约需要2分钟才能运行。将SQL Server查询放入存储过程时运行速度很慢

从SO以前的问题,我认为它可能给参数嗅探有关。当我在我的SP中声明了局部变量之前就已经有了这个问题,然后在整个过程中使用了局部变量。这在过去有效,但在这种情况下似乎没有帮助我。

我现在有

CREATE PROCEDURE dbo.ProcedureName 

    @DIV VARCHAR(4), 
    @STD VARCHAR(1), -- S or N 
    @scen varchar(20) 
AS 
BEGIN 

    DECLARE 
     @DIV_copy VARCHAR(4), 
     @STD_copy VARCHAR(1), 
     @scen_copy varchar(20); 
    SELECT 
     @DIV_copy = @DIV, 
     @STD_copy = @STD, 
     @scen_copy = @scen; 

我也尝试添加WITH RECOMPILE喜欢在我的SP中,像这样的结束使

CREATE PROCEDURE dbo.ProcedureName 

    @DIV VARCHAR(4), 
    @STD VARCHAR(1), -- S or N 
    @scen varchar(20) 

WITH RECOMPILE 
AS 
BEGIN 

    DECLARE 
     @DIV_copy VARCHAR(4), 
     @STD_copy VARCHAR(1), 
     @scen_copy varchar(20); 
    SELECT 
     @DIV_copy = @DIV, 
     @STD_copy = @STD, 
     @scen_copy = @scen; 

此外,我曾尝试加入OPTION(RECOMPILE)

SELECT * 
    FROM #Output 

OPTION(RECOMPILE) 

END 
GO 

我也尝试使用:

OPTION(OPTIMIZE FOR UNKNOWN) 

除了:

OPTION(QUERYTRACEON 4136) 

这个选项,我没有查询跟踪相应的权限。上述

无5个修复的出现来解决问题作为存储过程2分钟,2分钟,对于需要的存储过程的外侧1或2秒的相同查询到30秒之间仍然需要的任何地方。

这些修补程序都从这篇文章“Different Approaches to Correct SQL Server Parameter Sniffing

来有没有人有类似的问题?感谢您的时间!

的SQL Server 2008R2

+0

它听起来像参数嗅探,我没有任何其他想法它可能是。你可以查看这篇文章,看看它是否提供了你还没有尝试过的任何附加解决方案:http://www.sommarskog.se/query-plan-mysteries.html –

+0

'我尝试添加OPTION(RECOMPILE)at我的SP'结束 - 它应该放在违规查询之后。但是如果“重新编译”不起作用,我怀疑这个更正会。 –

+0

我有完全相同的症状,并创建params的本地副本始终解决它。唯一的区别是我总是使用SET语句而不是SELECT语句将值复制到局部变量中。 –

回答

0

可惜我没弄明白为什么同样准确的查询有这么多的麻烦放在一个存储过程中时相比,单独的SQL语句。

作为“解决方法”我花了一些时间在SP内部优化我的查询。我意识到我加入的一张表非常大(数百万行),所以我所做的就是从大表中获取相关数据并创建一个临时表来保存它,然后加入到(很多)较小的临时表中这似乎是诀窍。 SP现在在3-4秒内执行。

我还是有点新,所以我学习了很多基础知识以外的SQL语句。让我们来提醒您仔细查看您的疑问,但通常还有改进的空间。这感觉有点像透明胶带和回形针,但我的问题解决了。

谢谢大家对您的输入。

+0

而不是临时表格,您可能会通过向与匹配条件匹配的大表添加索引来做更好的工作。 –

+0

是的,但我没有权限这么做,尽管我可能会问我们的DBA团队。 – Soulfire

相关问题