Question

我有以下问题：当从我的应用程序中调用存储过程时，不时（如1000次调用中的1次），需要10-30秒才能完成。通常，sproc在一秒钟内运行。这是一个相当简单的proc，只有一个选择将几个表连接在一起。所有表名都设置了一个（NOLOCK）提示，因此可能没有锁定。索引也全部到位，否则它会一直很慢。

问题是我无法在SSMS中复制这个问题（因为它始终以亚秒级运行），无论它运行多少次sproc，但是当我将探查器指向正在运行我的应用程序的用户时，我看到了问题。 SSMS中的查询计划似乎是正确的，但问题仍然存在。

我从哪里开始？如何调试此问题？

Answer 1

一些选项：

探查者或SET STATISTICS xx ON说什么？是资源饥饿，比如说CPU

引擎决定统计信息已过期。表格是否按行数改变10％（经验法则）。测试：

SELECT
    name AS stats_name, 
    STATS_DATE(object_id, stats_id) AS statistics_update_date
FROM
    sys.stats 
WHERE
    object_id IN (OBJECT_ID('relevanttable1'), OBJECT_ID('relevanttable2'))

服务器上还发生了什么？示例：索引重建：不阻塞，只占用资源。

通常我建议参数嗅探，但你说每个调用的参数都是相同的。我也期望它更频繁地发生。

Answer 2

自动增长数据库？检查SQL错误日志中的消息。
由于插入记录而导致页面拆分？使用DBCC SHOWCONTIG
防病毒扫描？没有。
过时的统计数据？不要依赖对变化很大的表的自动更新统计信息。
不排除客户端上的问题或它们之间的联网。
使用持续时间过滤器运行探查器，仅捕获持续时间> 1的事件。 10秒，查找参数，客户，时间模式。

Answer 3

我会在SQL Server Profiler中设置一个跟踪，以查看应用程序用于连接的SET选项设置，以及SSMS中正在使用的设置。通过SET选项设置，我的意思是

ARITHABORT
ANSI_NULLS
CONCAT_NULL_YIELDS_NULL
//etc

查看MSDN以获取选项表

我之前看到SSMS和应用程序之间使用的set选项不同的问题（在特定情况下，它是ARITHABORT）并且性能差异很大（实际上，应用程序会超时）对于某些查询，取决于参数值。）

这是我建议开始调查的地方。通过设置跟踪，您将能够看到哪些特定呼叫花费的时间更长以及正在使用的参数。

Answer 4

在运行缓慢的运行中，传递给proc的参数有什么不同吗？

Answer 5

您是否完全确定它是数据库查询，而不是代码中的其他相邻逻辑？（即你之前和之后是否立即加上带时间戳的“追踪”陈述？）

Answer 6

对于我来说，Russ的建议对我来说是最有意义的，因为它听起来像是在查看分析器以验证计划是否已经过优化等等。

我还会关注数据类型的强制。也就是说，当varchar（60）参数与varchar（80）数据进行比较和索引时，我看到了类似的问题。在某些情况下，SQL Server会失去理智并强制扫描而不是搜索 - 尽管如此，我相信在这种情况下，您通常会在执行计划中看到这种情况。

可悲的是，另一个潜在的罪魁祸首（我有点怀疑因为它可能是一个红色的鲱鱼而抛出它）是超线程的。我已经看到它在过去[1]中做了类似的事情。

1 http://sqladvice.com/blogs/repeatableread/archive/2007/02/13/Burned-again-by-HyperThreading-on-SQL-Server-2000.aspx

Answer 7

重新编译存储过程然后看看会发生什么。这实际上有所帮助。

Answer 8

我也有类似的性能问题。将 WITH RECOMPILE 添加到SP有帮助。

这不是我所寻求的解决方案，但到目前为止我找不到更好......

请参阅： Slow performance of SqlDataReader

SQL Server 2005存储过程性能问题

8 个答案: