查询的实际执行计划显示总共需要2.040秒（计算每一步所用时间的总和），但需要52 秒（SQL Server Management Studio 底部显示的时间）才能完成。
为什么两个时代有如此大的差异？我怎样才能减少这 52 秒的时间？
SSMS中的消耗时间包括网络往返时间、客户端渲染时间等。
执行计划指示服务器处理查询花费了多长时间，而不是指示将结果流式传输给您花费了多长时间。
如果您要将数据输出到消息窗格，或者更糟糕的是，输出到网格，那么这不是免费的。当 SSMS 在网格中绘制数据时，服务器会通过网络向您发送行，但查询引擎不再执行任何操作。它的工作已经完成。
执行计划本身只知道查询在服务器上花费的时间。它不知道网络延迟或客户端处理速度慢。SSMS 会告诉您执行此操作花费了多少时间，而执行计划根本无法了解它，因为它是在 SSMS 完成其操作之前生成的。
执行计划在服务器上运行。它甚至不知道 SSMS 是什么，更不用说它对 236,833 行做了什么。让我们换个角度思考一下：
您购买了一些杂货，收银机收据显示您花了 4 分钟才结账。然后你走了很长的路回家，停下来喝咖啡，在进屋的路上把杂货扔在了家里，然后你花了 20 分钟才记住所有东西都去哪儿了。最后，你坐在沙发上。然后，收银机收据不会更新并添加您的出行时间和组织时间，这相当于 SSMS 在努力向您显示 236,833 行时所做的事情。
这就是为什么我们不会尝试通过添加现实世界中不会发生的不切实际的事情来计时查询的性能，因为现实世界中没有用户可以处理 200,000 行的任何内容。实际上，不要从客户端 GUI 中的测试中得出有关现实世界性能的任何结论。您的应用程序是否要进行分页、聚合或其他操作，以便最终用户不必等待 200,000 行呈现？如果是这样，请测试一下。如果不是，请重新考虑。
为了同时加快速度，请尝试使用 SSMS 中的“执行后丢弃结果”选项。
