如何度量存储过程的性能?

看看这篇文章: Measuring SQL Performance

如果您不想注册到免费帐户,这里有一个解决方案1:

DECLARE @start datetime, @stop datetime
SET @start = GETDATE()
EXEC your_sp
SET @stop = GETDATE()

第二:

SET STATISTICS TIME ON
EXEC your_sp

第三:

SET STATISTICS IO ON
EXEC your_sp

顺便说一句,这个网站有一些好文章。我建议注册。它是免费的。

问题是你在优化什么?是为了速度还是资源?

如果是speed,那么在查询分析器中,我将查看几次运行之间的执行情况,进行更改并再次计时。

如果它是资源,那么我将查看执行计划。如果是那样的话,我会从最坏的罪犯开始,一路沿着名单往下走。把它们加起来会告诉你总体性能,但大多数情况下,瓶颈是一个或两个项目。

如果你用的是

将Showplan设置为“全部打开”

查看带有过程名称exe的行的totalSubtreeCost列值

这可能有助于:

http://technet.microsoft.com/en-us/library/ms180765.aspx

像大多数问题一样,答案取决于…在最终分析中,唯一重要的度量是最终用户感知,它可能受到许多因素的影响,包括存储过程,以及网络性能、使用模式(存储过程是否被称为20x/天,还是1000x/秒?)等等,—并且存储过程可能不是决定因素。

但是,如果存储过程是对最终用户对某些函数的感知产生重大不利影响的“拼图-如果拼图”,则必须查看运行存储过程所用的时间。但这本身可能会受到许多基础度量的影响,要对此做任何事情,您需要对它们进行全部分析,以确定哪一个是整个存储过程性能的主要贡献者或覆盖贡献者。

您可以始终装配一个测试工具来调用存储过程并测量调用时间。不幸的是,您无法确切了解存储过程的哪些部分导致了速度减慢。

您总是可以手动在查询分析器中运行存储过程,并以这种方式测量结果。.NET线束只是为您自动化了这个过程。

简单的低眉毛解决方案是使用打印语句在各个部分打印执行时间。如果性能问题更为微妙并且只在生产环境中发现,那么这将不会有帮助,但是如果您可以在测试环境中重现它,那么您就应该没事了。

如果您试图比较两个过程或语句的性能,一种简便的技术是在查询分析器中同时选择两个SQL块并运行查询计划。该计划将告诉您每个块相对于另一个块的成本百分比。这不是充分的证据。我看到它告诉我,当它明显更昂贵的时候,它实际上运行更便宜,但在大多数情况下,这是一个不错的,快速的技巧。