SQL Server查询随着时间的推移从0降低到60毫秒

我需要一些帮助来解释SQL Server 2008中的这种行为。我有一个简单的C++程序在循环中运行查询。这是程序的伪代码。SQL Server查询随着时间的推移从0降低到60毫秒

myTempid = 0; 

while (1) { 
    execQuery(select a.id 
      from a,b,c,d 
      where a.id = b.id 
       and b.id = c.id 
       and c.id = d.id 
       and id.id = myTempID) 
}

这里有一些事实

A，B，C都是空表
d具有约5500行

查询开始时采取 '0msec'（我可以从分析器中看到这一点）;但是在X次迭代之后;它跳到约60毫秒并停留在那里。 X是变体;有时是100 ..有时是200.奇怪的是，一旦它从0跳到60毫秒，无论myID如何，它都会停留在那里。

对我来说，听起来像SQL Server是以某种方式'去缓存'的查询计划？这对任何人都有意义吗

谢谢！

来源

2010-08-01 shergill

什么是id.id？你确定在execQuery例程中没有内存或连接泄漏吗？ – Jacob 2010-08-01 02:50:51

您是在SQL服务器上还是在您的应用中计时执行？如果在你的应用程序中，这可能会打开连接或打开一个最大值。 – Bill 2010-08-01 03:50:30

可能是参数嗅探：http://www.sqlpointers.com/2006/11/parameter-sniffing-stored-procedures.html – 2010-08-01 03:59:33

来自SQL事件探查器的结果可能会很难理解。

显示的命令时间包括记录集传递给客户端的时间。为了看到这个，创建一个返回至少一百万行的SELECT语句。运行这些测试是SQL Management Studio并运行SQL Profiler来跟踪结果。

首先运行，将SQL结果发送到一个临时表（应该需要一秒左右）。第二次运行，将SQL结果发送到结果窗口（应该需要几秒钟）。请注意SSMS中显示的运行时间。然后记下SQL Profiler报告的时间。

您应该看到SSMS读取记录集，格式化结果并将它们显示到“结果”窗口的时间会增加为查询报告的持续时间。

毕竟，我说当你从你的应用程序运行查询时，在这个精确度级别（60毫秒）下，你无法判断数据库，网络或应用程序的降速来自哪里，只是从报告的持续时间。

您应该创建一个测试脚本并在SSMS中运行查询，查看当您的应用程序不是循环的一部分时查询时间是否会降低。

SQL事件探查器2008以微秒记录持续时间，但仅以毫秒显示;所以舍入是一个问题。将跟踪保存为跟踪表并查看“持续时间”列中的结果以查看微秒。如果问题出在SQL Server中，您可能会看到持续时间在增加。

您还可以让Profiler返回执行计划。您可以在持续时间增加之前和之后查看执行计划，并查看执行计划是否正在改变。

来源

2010-08-01 04:06:50

SQL Server查询随着时间的推移从0降低到60毫秒

回答

相关问题