您必须运行“最佳实践”
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
在对SQL查询进行性能分析之前。
然而，例如，后来的一个DROPCLEANBUFFERS：
使用DBCC DROPCLEANBUFFERS使用冷缓冲区缓存测试查询 没有关闭并重新启动服务器。
要从缓冲池中删除干净的缓冲区，首先使用CHECKPOINT 生成一个冷缓冲区缓存。这会强制所有脏页面 要写入磁盘并清理缓冲区的当前数据库。后 你这样做，你可以发出DBCC DROPCLEANBUFFERS命令来删除所有 来自缓冲池的缓冲区。
我想，这意味着您将测试您的查询，就好像它是在服务器中运行的第一个查询，因此查询的实际“真实”影响将会更低。
是否真的建议运行这三个命令来了解查询成本，或者它是否能让您获得与实时环境中的实际查询时间无关的实证结果？
答案 0 :(得分：8)
我不同意这是最佳做法，很少使用它。
我调整的查询应该是一个流行的，经常运行的查询。这给了我最大的收获。对于计划或数据，它应该很少“冷”。
我正在测试查询执行：不是磁盘读取系统或查询优化器编译
前一段时间，这是在DBA.SE上提出来的。请看这些
答案 1 :(得分：7)
是否真的建议运行这三个命令来了解查询成本，或者它是否能让您获得与实时环境中的实际查询时间无关的实证结果？
取决于。
如果您没有运行DBCC DROPCLEANBUFFERS，那么除非您非常小心进行性能分析，否则您可能会得到一些奇怪的结果。例如，一般来说，第二次运行查询会更快，因为所需的页面可能会缓存在内存中 - 运行DBCC DROPCLEANBUFFERS会有帮助，因为它可以确保您在测试中有一个一致的起点确保您的查询不是人为地快速运行，因为它正在跳过查询中昂贵的磁盘访问部分。
然而，就像你说的那样，在实时环境中，这些数据可能总是被缓存，因此你的测试不能代表生产条件 - 这取决于你是否根据数据的假设来分析性能经常访问，因此通常会被缓存，或不经常访问，因此可能涉及磁盘助手。
简短的回答是，运行这3个语句可以帮助确保在性能测试时获得一致的结果，但是在测试之前，您不一定始终运行这些语句，而应该尝试理解什么与生产环境相比，每个人都会对您的查询产生什么影响。
除此之外，从不在生产服务器上运行这3个语句中的任何一个，除非您知道完全您正在做什么！
答案 2 :(得分：3)
我同意@gbn在他的回答中所说的内容，我认为除了展示可能方法之间的差异之外，我还没有将这三个命令用于其他任何事情。
此外，在大多数情况下，仅在测试时在生产环境中运行这三个DBCC是不明智的。无论如何，在测试环境中使用测试数据和测试负载进行性能调优查询通常会导致您对查询得出错误的结论。
通常，当我调整查询时，我使用分析器从实时获取实际执行统计数据，我使用SSMS从实时获取执行计划，并进行一些测试运行（在测试数据上）以查看不同之处。对于更棘手的问题，我还使用Windows性能监视器 - 并且始终处于尽可能接近真实状态的情况。运行DBCC只会从实际交易中删除调优工作。