当我运行从 Sql 管理工具中返回数百万行的查询时，看起来查询会立即执行。据我所知，几乎没有执行时间。使查询需要时间完成的原因是返回所有行。 这让我觉得我做得很好！但不是那么快......当我查看分析器工具中的查询时，它指出查询使用了 7600 CPU。持续时间为 15000。
我不确定我知道如何解释这些统计数据。 一方面，查询似乎运行得很快，但探查器报告让我不这么认为。为什么查询会在 Mgmt Tools 中立即执行？据我所知，显然应该有某种延迟执行：至少 7600 毫秒。当我在 mgmt 工具中运行查询时，我必须等待比 cpu 和持续时间统计更长的时间才能完成查询。
【问题讨论】：
标签： sql-server sql-server-2005 tsql
看起来查询会立即执行
可能是查询计划允许开始快速返回行。
例如，如果您执行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 上发布另一个问题。
【讨论】：
SELECT INTO 或向查询添加虚假聚合，SSMS 中有一个选项“执行后丢弃结果”