SQL Server 2005 存储过程性能问题 [英] SQL Server 2005 stored procedure performance problem

问题描述

我有以下问题:从我的应用程序调用存储过程时，时不时地(例如 1000 次调用中的 1 次)，完成需要 10-30 秒.通常，sproc 会在一秒钟内运行.这是一个相当简单的过程，具有将几个表联系在一起的单个选择.所有表名都设置了 (NOLOCK) 提示，因此它可能没有锁定.索引也都到位了，不然一直很慢.

I have the following issue: when a stored proc is called from my application, every now and then (like 1 time out of 1000 calls), it takes 10-30 seconds to finish. Typically, the sproc runs in under a second. It's a fairly simply proc with a single select that ties together a couple of tables. All the table names are set with a (NOLOCK) hint, so it probably isn't locking. The indexes are all in place too, otherwise it would be slow all the time.

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

The problem is that I can't replicate this issue in SSMS (as it always runs subsecond) no matter how many times it runs the sproc, yet I see the problem when I point the profiler to the user who's running my app. The query plan in SSMS seems correct, yet the problem persists.

我该往哪里去?我该如何调试这个问题?

Where do I go from here? How do I debug this issue?

推荐答案

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

这篇关于SQL Server 2005 存储过程性能问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！