我有一个非常恶心的存储过程，几个月前并不慢，但现在是。我几乎不知道这件事是什么，我也没有兴趣重写它。Sql Server 2000存储过程阻止并行或什么？
我知道，如果我拿着存储过程的主体，然后声明/设置参数值并在查询分析器中运行它，它运行速度提高了20倍以上。
从互联网上，我读到，这可能是由于一个不好的缓存查询计划。所以，我试过在EXEC之后用“WITH RECOMPILE”运行sp，并且我也尝试过在内部放置“WITH RECOMPLE”，但这两者都没有帮助。
当我查看sp与查询的执行计划时，最大的区别是sp在整个地方都有“并行性”操作，查询没有任何操作。这可能是速度差异的原因吗？
谢谢，任何想法都会很棒......我被卡住了。
如果两个查询计划之间的唯一区别是并行性，请尝试将OPTION (MAXDOP 1)放在查询的末尾以将其限制为序列计划。至于为什么它们不同，我不确定，但我记得SQL Server 2000优化器是这样的，呃，finicky。与您的情况类似，我们通常看到的是临时查询批次会很快，而通过sp_executesql进行的相同查询会很慢。从未完全弄清楚发生了什么事。尽管如此，串行并行可以明确地解释速度的不同。在SQL Server 2000上，并行计划use all the processors on the machine不仅仅是它需要的那些：
如果SQL Server选择使用并行性，它必须使用所有配置的处理器（由MAXDOP查询提示配置确定）执行平行计划。例如，如果在32路服务器上使用MAXDOP = 0，则与仅使用一个处理器的串行计划相比，即使七个处理器可以更有效地执行作业，SQL Server也会尝试使用全部32个处理器。由于这种全有或全无的行为，如果SQL Server选择并行计划并且不限制MAXDOP查询提示[...]，那么需要SQL Server协调高端服务器上所有处理器的时间超过使用并行计划的优势。
默认情况下，我认为服务器范围内的MAXDOP设置为0，表示尽可能多地使用。如果您最近使用更多处理器升级了数据库服务器以提高性能，这可能会讽刺地解释您的性能受到影响的原因。如果是这样的话，你可以尝试设置MAXDOP提示以前的处理器数量，看看是否有帮助。
我知道，如果我带的 存储过程中的身体，然后 声明/设置 参数的值，并在查询运行它，它运行超过20倍 更快 分析。
你确定它不是在SP执行之前获取这些参数吗？这不会导致你的缓慢？绕过这些参数的人群，你可能会过分简化你的问题。
这些参数从何而来？他们是如何填充的？从你的问题看来，你已经隔离了存储过程并发现它可能不是问题。
尝试在过程的顶部添加SET ARITHABORT ON。
很高兴知道，但这也没有帮助。我想我应该提及它没有进行任何聚合或计算。不过谢谢。 – 2010-03-19 14:26:52
如果您已经对报表进行了很多的变化，而不是运行重新索引或碎片整理上有问题你应该表。看看这article。我建议这样做的原因是因为程序一度很快，现在随着时间的推移它的性能下降了。我不认为对已经测试过并且一次很好运行的已有程序的更改应该随着时间的推移而发生变化，因为这会改变性能。这通常只处理症状而不是实际问题。
完全有效，我会试一试。但是，我想我对这个时候存储过程出了什么问题更感兴趣。例如，如果索引完全分散，那么常规查询如何解决这个问题并仍然很快？ – 2010-03-19 14:35:20
它可能是一个争用问题吗？此商店程序是否在特定时间运行，此时还有其他繁重事件发生？
我很难编码我的参数。我在查询分析器中字面上有以下内容。创建程序someProc（@a int）*** body *** go EXEC someProc 5 ------------------------------- - 声明@a int set @ a = 5 *** body ***我突出了EXEC语句，它需要24秒。我强调了这个查询，它需要1秒。 – 2010-03-19 14:25:17