症状是我们的数据库服务器在运行从特定表中选择数据的存储过程时偶尔会发出超时异常。它每周一次这样做。我们重新启动数据库，事情似乎正常运行。如果我们等待几分钟，它有时会自行恢复。
在我们更改了有问题的表上的聚簇索引之后，这种情况就开始发生了，这是一个很大的（900k行），经常查询的表。
我们显然需要缓解这种情况，但我们找不到数据库服务器开始超时的情况。我已经检查了sys.dm_exec_query_stats表，但我似乎无法找到导致问题的特定存储过程，更不用说传递给该存储过程的值会导致性能降低。
在SQL服务器中是否存在某种更精细的日志记录，我可以使用它来查找导致性能降低的特定查询或存储过程？然后，一旦我发现，有没有办法在参数中看到传递给该存储过程或查询的值？
答案 0 :(得分：3)
一种可能性是使用SQL Profiler（或某些类似的工具）来指出缓慢的那些，并将精力集中在那里。
答案 1 :(得分：0)
我们的DBA使用一种方法，该方法有效地涉及运行存储过程的SQL代理作业（大约每20秒左右），该操作将对 sp_WhoIsActive 的调用输出记录到表中。 sp_WhoIsActive可以输出有关当前活动查询的各种有用信息，包括执行时间和执行计划。
答案 2 :(得分：0)
听起来好像很多东西。例如，您可能在表上没有足够的索引。执行计划说了什么？是否有桌面扫描？
如果查询时间发生变化，则听起来像是过时的统计信息。尝试更新统计数据，看看是否有帮助。
另外，只是旁注。如果您不希望SqlCommand对象超时，请将CommandTimeout设置为零。