O.O Asked: 2012-01-21 09:46:07 +0800 CST2012-01-21 09:46:07 +0800 CST 2012-01-21 09:46:07 +0800 CST 如何获得准确的查询性能？ 772 我正在尝试提高存储过程的性能。当我运行 SP 时，它几乎立即完成，就好像某些东西被缓存了一样。在 SSMS 中执行 SP 之前，有人告诉我使用以下两行 SQL： DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE 当我使用上面的两行代码运行 SP 时，SP 大约在 8 秒内完成。但是，这真的给了我真正的执行时间吗（就像我从应用程序运行它一样）？我怎么知道？ sql-server-2008 ssms 1 个回答 Voted Best Answer JNK 2012-01-21T10:13:52+08:002012-01-21T10:13:52+08:00 这些命令做两件事： 清除页面缓存，其中存储已经从磁盘检索到的数据页面（通常查询中最大的时间因素是磁盘访问） 清除查询计划缓存，这意味着服务器需要创建一个新的查询计划。除了非常高的交易量外，这通常并不重要。 你基本上得到了一个相当于“最坏情况”场景的时间——你刚刚重新启动了服务器，内存中没有任何内容。后续运行不需要支付从磁盘中提取数据的成本，因为这些页面已经加载到内存中。 这类似于现实世界的情况 - 假设您正在检查相同的数据，您运行特定查询的第一个用户可能需要等待比后续运行更长的时间。 我喜欢使用的一个好方法是多次运行并取平均值。这在共享环境中特别有用，因为您无法完全控制像 tempdb 这样的共享资源。 您还可以使用这些命令来获取有关幕后实际发生的事情的更多信息： SET STATISTICS IO ON SET STATISTICS TIME ON 这些将为您提供有关从磁盘读取的页面（每个对象）、逻辑页面读取、编译计划所花费的时间以及执行查询所花费的时间的详细信息。
这些命令做两件事：
你基本上得到了一个相当于“最坏情况”场景的时间——你刚刚重新启动了服务器，内存中没有任何内容。后续运行不需要支付从磁盘中提取数据的成本，因为这些页面已经加载到内存中。
这类似于现实世界的情况 - 假设您正在检查相同的数据，您运行特定查询的第一个用户可能需要等待比后续运行更长的时间。
我喜欢使用的一个好方法是多次运行并取平均值。这在共享环境中特别有用，因为您无法完全控制像 tempdb 这样的共享资源。
您还可以使用这些命令来获取有关幕后实际发生的事情的更多信息：
这些将为您提供有关从磁盘读取的页面（每个对象）、逻辑页面读取、编译计划所花费的时间以及执行查询所花费的时间的详细信息。