我有一个巨大恶心的存储过程,几个月前并不慢,但现在是。我几乎不知道这件事是做什么的,我对重写它毫无兴趣。
我知道如果我获取存储过程的主体然后声明/设置参数的值并在查询分析器中运行它运行速度超过20倍。
从互联网上,我读到这可能是由于错误的缓存查询计划造成的。所以,我在EXEC之后尝试使用“WITH RECOMPILE”来运行sp,并且我也尝试将“WITH RECOMPLE”放在sp中,但这些都没有帮助甚至一点点。
当我查看sp与查询的执行计划时,最大的区别是sp在整个地方都有“Parallelism”操作,而查询没有任何操作。这可能是速度差异的原因吗?
谢谢,任何想法都会很棒......我被卡住了。
答案 0 :(得分:4)
如果两个查询计划之间的唯一区别是并行性,请尝试将OPTION (MAXDOP 1)
放在查询的末尾,以将其限制为一个串行计划。
至于为什么它们不同,我不确定,但我记得SQL Server 2000优化器是,嗯,挑剔。与您的情况类似,我们通常看到的是,即席查询批次会很快,而sp_executesql
的同一查询会很慢。从来没有完全弄明白发生了什么。
如果SQL Server选择使用并行性,则必须使用所有已配置的处理器(由MAXDOP查询提示配置确定)来执行并行计划。例如,如果在32路服务器上使用MAXDOP = 0,则与仅使用一个处理器的串行计划相比,即使七个处理器可能更有效地执行作业,SQL Server也会尝试使用所有32个处理器。由于这种全有或全无的行为,如果SQL Server选择并行计划并且您不限制MAXDOP查询提示[...],那么SQL Server协调高端服务器上所有处理器的时间超过使用并行计划的优势。
默认情况下,我认为MAXDOP
的服务器范围设置为0,表示尽可能多地使用。如果您最近使用更多处理器升级数据库服务器以帮助提高性能,那可能会讽刺地解释您的性能受到影响的原因。如果是这种情况,您可以尝试将MAXDOP
提示设置为您之前使用的处理器数量,看看是否有帮助。
答案 1 :(得分:1)
尝试在程序的顶部添加SET ARITHABORT ON
。
答案 2 :(得分:1)
如果您对表进行了很多更改,并且没有对相关表进行重新索引或碎片整理,那么您可能应该这样做。看看这个article。我之所以这样做的原因是因为这个程序很快就会很快,而且随着时间的推移它会降低性能。我不认为对已经测试并且一次运行良好的现有程序进行更改应该因性能随时间降低而改变。这通常只处理症状而非实际问题。
答案 3 :(得分:0)
我知道如果我拿走身体的话 存储过程然后 声明/设置的值 参数并在查询中运行它 分析仪,它运行超过20倍 更快。
你是否确定在SP的执行之前不是这些参数的获取不会导致你的缓慢?绕过params的人口,你可能会过分简化你的问题。
这些参数来自哪里?它们是如何填充的?从您的问题看来,您已经隔离了存储过程并发现它可能不是问题。
答案 4 :(得分:0)
这可能是争用的问题吗?当其他繁重的工作也发生时,这个商店程序是否会在特定时间运行?