Question

我们遇到了sp。

的问题

我们有一个非常简单的sp包含一个声明的表和几个外连接，最后返回20到100行。

由于查询此sp一直给我们在生产和测试环境中表现不佳，我们最近将其重写为更高效，并且在我们的测试环境中进行了彻底的测试。

我们将它发布到生产中只是为了发现它仍然很慢并且导致我们的.NET 2.0应用程序在被调用时超时。

我们什么都不懂，在生产数据库上进入Management Studio并在那里运行sp，它在1秒内执行。

也就是说，当从我们的应用程序运行时，它非常慢并且导致超时，当从Management Studio运行时它非常快并且从不需要超过一秒钟。

对SQL Server 2005有深入了解的人可以给我们一个暗示吗？

Answer 1

我认为您的问题可能是“参数嗅探”。这是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

Answer 2

重新编译是一种钝器。这很可能是参数嗅探

请参阅此问题：Stored Procedure failing on a specific user

Answer 3

对于回复家伙来说，似乎正在运行sp_recompile解决了这个问题，至少自从我昨天下午执行它以后，一切都一直在运行，会继续观察它，看看它是否保持快速。

但是，当我更改sp？

中的内容时，不要理解我没有重新编译

Answer 4

确保您的生产数据库具有最新的统计信息，并且索引状况良好（如果可能，请考虑重建所涉及的索引）。

Answer 5

您能确定没有发生死锁的情况吗？管理工作室的运行将被隔离，从应用程序可能是更大的交易的一部分。

Answer 6

我建议您在 SSMS 中更改您的首选项，以便您默认连接 ARITHABORT OFF 以避免这种混淆。但是与应用程序具有相同的设置实际上有一个小缺点：您可能没有观察到性能问题与参数嗅探有关。但是，如果您在调查性能问题时养成在 ARITHABORT ON 和 OFF 时运行问题过程的习惯，您就可以轻松判断是否涉及参数嗅探。

看看这些链接： https://www.sommarskog.se/query-plan-mysteries.html#sniffinfo

https://docs.microsoft.com/en-us/sql/t-sql/statements/set-arithabort-transact-sql?view=sql-server-ver15

存储过程仅在从应用程序运行时导致超时

6 个答案: