SQL Server 定期固定延迟答案

【问题标题】：SQL Server Periodic Fixed DelaysSQL Server 定期固定延迟
【发布时间】：2013-05-23 14:11:31
【问题描述】：

我们正在使用 PHP 5.3 和 pdo_dblib 连接到另一个机器上的 SQL Server 2008。

定期（一天中随机 10 次以上）我们会经历 3 分钟的时间段，所有 SQL Select 查询将需要 21.01 秒才能运行，无论查询如何。这是在 PHP 中计时的（在 DB 查询之前和之后）。

SELECT 语句的范围从具有优化的复杂连接到具有单个表和显式索引的语句。

如果在 PHP 请求期间，我们在关闭数据库连接之前执行三个 SELECT 语句，总时间将为 63.03 秒 (21.01 * 3)。这同样适用于 2 个语句（42.02 秒）。

使用 SQL Server 工具，我们跟踪这些脚本的实际执行时间在 0.01 到 0.45 秒之间，但这些差异似乎并未反映在整体延迟上（它始终固定在 21.01，而不是 21.46等）。

我们似乎确实发现了在这些延迟期开始时触发 WinHTTP 代理的一些相关性，但我们已经禁用了 WinHTTP 代理，但没有任何解决方案。

有什么建议吗？

【问题讨论】：

您指的是哪些 SQL Server 工具？ Profiler 还是 SSMS？
使用了 SSMS。所有执行时间都不到 1 秒。
如果您还没有使用它们，您应该考虑监控标准性能计数器和服务器的等待统计信息。这些，当与良好的服务器端跟踪一起使用时，通常可以解决问题。
有很多原因可能导致这种情况。其中有几个是糟糕的索引、索引碎片、过时的统计信息和 IO 争用（仅举几例）。此外，来自网络本身的 IO 延迟、请求的数据量以及应用程序使用它的方式并不少见。
即使在没有连接和显式索引的 SELECT 上？这些事务通常需要 0.01 秒，但在一天中的 10 个随机时刻，在 3 分钟内，它们恰好需要 21.01 秒（无论选择如何）。

【解决方案1】：

当您查看这些执行计划时，哪些活动占用了最大比例的资源？我会特别注意索引扫描或键/书签/RID 查找。我还会查看连接每个活动的线路，看看有多少记录被应用。最后，使用实际查询计划而不是估计计划运行查询，然后查看每个操作返回的实际与估计行。他们应该是平等的。如果不是，则说明您的统计信息已关闭。

【讨论】：

所有索引都明确说明，因此不涉及计划执行估计器。我们相当确信它是与手头的 PCAP 数据相关的陈旧连接，并且没有记录运行超过 3 秒的查询（这些是存储过程查询）。我们更新了统计数据，但仍然发生。