SQL Server 2000存储过程如何避免并行处理或其他相关问题？

Question

我有一个巨大且令人讨厌的存储过程，几个月前它还不慢，但现在却变得很慢。我几乎不知道这个东西在做什么，也不想重写它。

我知道如果我拿出存储过程的主体，然后声明/设置参数的值，并在查询分析器中运行它，它会比原来快20倍以上。

从互联网上看，这可能是由于缓存的查询计划不好所致。因此，我尝试在EXEC之后使用“WITH RECOMPILE”运行sp，也尝试将“WITH RECOMPILE”放入sp中，但都没有帮助。

当我查看sp和查询的执行计划时，最大的区别在于sp有“Parallelism”操作，而查询没有任何操作。这可能是速度差异的原因吗？

谢谢，任何想法都可以，我被卡住了。

- internet man

Answer 1

如果两个查询计划之间唯一的区别是并行性，尝试在查询末尾加上OPTION (MAXDOP 1)来将其限制为串行计划。

至于它们为什么不同，我不确定，但我记得SQL Server 2000优化器很挑剔。与您的情况类似，我们通常看到的是adhoc查询批处理速度快，而通过sp_executesql执行相同的查询速度却慢。我们从未完全弄清楚发生了什么。

串行与并行肯定可以解释速度差异。在SQL Server 2000上，并行计划使用机器上的所有处理器，而不仅仅是需要的处理器：

如果SQL Server选择使用并行处理，则必须使用所有已配置的处理器（由MAXDOP查询提示配置确定）来执行并行计划。例如，在32路服务器上使用MAXDOP = 0时，SQL Server尝试使用所有32个处理器，即使7个处理器可能比仅使用一个处理器的串行计划更有效率。由于这种全有或全无的行为，如果SQL Server选择并行计划并且您没有限制MAXDOP查询提示[...]，则协调高端服务器上的所有处理器所需的时间会超过使用并行计划的优势。

默认情况下，我认为服务器范围内的MAXDOP设置为0，表示尽可能多地使用处理器。如果您最近升级了数据库服务器以提高性能，这可能反而解释了为什么您的性能受到影响。如果是这种情况，您可以尝试将MAXDOP提示设置为之前的处理器数量，看看是否有所帮助。

- Tadmas

Answer 2

尝试在过程的顶部添加SET ARITHABORT ON。

如此处所示：https://stackoverflow.com/questions/2465887/why-would-set-arithabort-on-dramatically-speed-up-a-query

- KM.

---

好知道，但那也没有帮助。我想我应该提到它不进行任何聚合或计算。谢谢。 - internet man

Answer 3

如果您对表进行了许多更改，但没有在相关的表上运行重新索引或碎片整理，那么您可能应该这样做。请查看此文章。我建议这样做的原因是因为该过程曾经很快，但随着时间的推移，性能已经下降。我认为，对于已经测试并且一度良好工作的现有过程进行更改，不应该因为随着时间的推移而导致性能下降而改变。这通常只是治疗症状而非实际问题。

- Random Developer

---

完全有效，我会尝试一下。然而，我猜现在我更感兴趣的是存储过程出了什么问题。例如，如果索引完全分散，正常查询如何绕过它并保持快速？ - internet man

Answer 4

我知道如果我拿到存储过程的主体，然后声明/设置参数的值并在查询分析器中运行它，它会比原来快20倍以上。

你确定不是在存储过程执行之前获取这些参数导致了速度变慢吗？通过绕过参数的填充，你可能会过于简化问题。

这些参数来自哪里？它们是如何填充的？从你的问题中看来，你已经隔离了存储过程，并发现它可能不是问题的根源。

- Paul Sasik

---

我正在硬编码我的参数。在查询分析器中，我实际上有以下内容。 create procedure someProc(@a int) body go EXEC someProc 5 --------------------------------- declare @a int set @a=5 ***body *** 我突出显示EXEC语句需要24秒。我突出显示查询只需要1秒钟。 - internet man

Answer 5

可能是竞争的问题吗？这个存储过程是否在其他繁重操作同时进行的特定时间运行？

- user287466