当我运行一个从Sql Management工具中返回数百万行的查询时，它看起来就像查询立即执行一样。据我所知，几乎没有执行时间。使查询花费时间完成的原因是返回所有行。 这让我觉得我做得很好！但不是那么快......当我在profiler工具中查看查询时，它表明该查询使用了7600 CPU。持续时间为15000。
我不确定我是否知道如何解释这些统计数据。 一方面，查询似乎运行得很快，但是分析器报告让我想到了。为什么在Mgmt Tools中立即执行查询？据我所知，显然应该有某种延迟执行：至少7600毫秒。当我在mgmt工具中运行查询以完成查询时，我必须等待比cpu和持续时间统计更长的时间。
答案 0 :(得分：3)
看起来查询立即执行
可能是查询计划允许开始快速返回行
例如，如果执行SELECT * FROM a_large_table，您将立即看到一些行，但检索整个结果集将需要一些时间。 Mgmt Studio报告的实际执行时间是什么（查询完成后显示在状态栏中）？
如果要在不向客户端检索数据的情况下测试查询性能，可以执行SELECT INTO #temp_table。这需要一些额外的I / O，但仍然会给你一个相当好的执行时间估计。
UPD。
你也可以运行类似SELECT COUNT(*) FROM (<your query here>)或SELECT SUM(<some field>) FROM (<your query here>)的东西 - 运气好的话，它会让服务器执行查询并聚合结果，基本上做同样的工作加一点额外的工作。但是很容易以这种方式扭曲结果 - 查询优化器是聪明的，你需要非常小心，以确保你正在测量你想要测量的东西（因为用不同的执行计划测量查询根本就没有意义）。
我建议你再考虑一下你想要衡量的内容和原因。在任何现实场景中，您对“纯”查询持续时间不感兴趣 - 因为您永远不想丢弃查询结果（结果就是您首先需要此查询的原因，对吧？）。因此，您需要将结果返回给客户端，或者将其存储在某个地方，或者将其与另一个表连接等等 - 通常您需要测量查询执行，包括用于处理结果的时间。
最后一个通知。如果你希望你能以某种方式迫使服务器在1秒钟内执行这个查询，因为你认为服务器在其他13秒内什么都不做，那你就错了。正如他们所说，SELECT没有被破坏。
可能对查询优化有所帮助 - 对于单个查询，分析器对您没有多大帮助。分析查询计划，调整表结构，尝试重写查询，如果遇到问题就在SO上发布另一个问题。