您必须运行"最佳实践"
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
Run Code Online (Sandbox Code Playgroud)
在对SQL查询执行性能分析之前.
然而,例如,后来的一个DROPCLEANBUFFERS:
使用DBCC DROPCLEANBUFFERS使用冷缓冲区缓存测试查询,而无需关闭并重新启动服务器.
要从缓冲池中删除干净缓冲区,首先使用CHECKPOINT生成冷缓冲区缓存.这会强制将当前数据库的所有脏页写入磁盘并清除缓冲区.执行此操作后,您可以发出DBCC DROPCLEANBUFFERS命令以从缓冲池中删除所有缓冲区.
我猜,这意味着您将测试您的查询,就好像它是在服务器中运行的第一个查询,因此查询的实际"真实"影响将更低.
是否真的建议运行这三个命令来了解查询成本,或者它是否能让您获得与实际环境中的实际查询时间无关的实证结果?
我不同意这是最佳做法,很少使用它.
我调整的查询应该是一个流行的,经常运行的查询.这给了我最大的收获.对于计划或数据,它应该很少"冷".
我正在测试查询执行:不是磁盘读取系统或查询优化器编译
这是前一段时间在DBA.SE上提出来的.请看这些
是否真的建议运行这三个命令来了解查询成本,或者它是否能让您获得与实际环境中的实际查询时间无关的实证结果?
这取决于.
如果你没有跑,DBCC DROPCLEANBUFFERS那么你有可能会得到一些奇怪的结果,除非你非常小心你的表现分析方式.例如,一般来说,第二次运行查询会更快,因为所需的页面可能缓存在内存中 - 运行有DBCC DROPCLEANBUFFERS帮助,因为它确保您在测试中具有一致的起点,并确保您的查询是不是因为它正在跳过查询中昂贵的磁盘访问部分而人为地快速运行.
但是,就像你说的那样,在实时环境中,这些数据可能总是被高速缓存,因此你的测试不能代表生产条件 - 这取决于你是否根据数据频繁访问的假设分析性能因此通常会被缓存或不经常访问,因此可能涉及磁盘助手.
简短的回答是,运行这3个语句可以帮助确保在性能测试时获得一致的结果,但是您不一定总是在测试之前运行这些语句,而应该尝试了解每个语句的作用以及它将对其产生的影响.与生产环境进行比较时的查询.
另外,除非您确切知道自己在做什么,否则切勿在生产服务器上运行这3个语句中的任何一个!
| 归档时间: |
|
| 查看次数: |
11339 次 |
| 最近记录: |