【发布时间】：2011-04-29 03:30:38
【问题描述】：
在 SQL Server 2005 管理工作室中，我正在测试一个使用一些表变量的查询，其中一个变量有一个集群唯一约束。我注意到当我包含实际执行计划来分析它时，总执行时间实际上下降了很多。
这是什么原因，我是否应该只在包含执行计划的选项关闭时测试总执行时间。
谢谢！
【问题讨论】：
标签： sql sql-server performance testing sql-execution-plan
【发布时间】：2011-04-29 03:30:38
【问题描述】：
对我来说听起来有点奇怪。您确定您看到的差异不在于缓存吗？ 我总是通过不包括执行计划来测试存储过程的性能，并且我会在每次运行之前清除缓存以便进行公平比较（在测试/开发数据库服务器上，而不是生产上）。
DBCC FREEPROCCACHE -- will clear the execution plan cache
DBCC DROPCLEANBUFFERS -- will clear the data cache
【讨论】：
-
当我运行 DBCC DROPFREEBUFFERS 时出现错误 -- DBCC 语句不正确。当我用谷歌搜索它时，命令 DBCC DROPCLEANBUFFERS 出现了。
-
好吧，我在语句之前使用 DBCC FREEPROCCACHE 和 DBCC DROPCLEANBUFFERS 命令对其进行了测试，并且在打开 Show Execution Plan 时它仍然更快。我想知道它是否与统计有关，如果是的话，当我在生产环境中运行查询时，如何才能获得更快的结果集。
-
我会将您的答案标记为正确。虽然我还是不明白为什么会这样，但这可能是客户端统计的统计方式的一个错误，也许它们不包括执行计划显示打开时创建执行计划的时间，或者类似的东西.您有关清除缓存的提示帮助我获得了两次尝试之间的总执行时间的良好基线，因此感谢您。
我刚刚遇到了同样的问题，在尝试了解包含执行计划如何或为什么会加快速度之后，我现在得出的结论是 SSMS 只是误报了总执行时间。因此，您的问题的答案是，遗憾的是，它并没有真正运行得更快，是的，您应该在不包含执行计划的情况下执行计时。
最初执行时间为几百毫秒的测试时，很难诊断，但一旦我能够用较慢的查询重现问题，就更容易看到了。下面的屏幕截图是一个存储过程的五次运行，它返回多个结果集。前三个运行没有返回执行计划，第四和第五次运行。尽管响应速度明显更快（约 200 毫秒而不是约 5 秒），但查询实际上仍需要约 5 秒才能完成。我猜在某个地方的客户端统计信息中有一个错误，它正在计时返回的执行计划，而不是在某些情况下的完整查询。
【讨论】：