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