在Google搜索中,我可以查找以下命令:
DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE
实际上,在执行几次查询之后,我的查询比以前花费了更实际的时间。但是,我不确定这是推荐的技术。
最佳实践是什么?
#1 楼
就个人而言,对于常见查询而言,第二次及其后的执行更为重要。要测试磁盘IO或查询性能吗?
假设您的查询经常运行并且很关键,那么您想在现实生活中进行测量。而且您不想每次都清除产品服务器缓存...
如果需要,您可以:
DBCC DROPCLEANBUFFERS
清除干净缓冲池中的(未修改的)页面先用
CHECKPOINT
首先将所有脏页刷新到磁盘上DBCC FLUSHPROCINDB
清除该数据库的执行计划也请参见(在DBA.SE上)
使用SQL Profiler解决高页面加载时间
#2 楼
答案较晚,但可能对其他读者有用。DBCC DROPCLEANBUFFERS
是用于查询测试和衡量查询执行速度的常用命令。该命令(运行时)仅保留脏页,而脏页实际上只是一小部分数据。它会删除整个服务器的所有干净页面。请注意,此命令不应在生产环境中运行。运行此命令将导致缓冲区缓存大部分为空。在执行
DBCC DROPCLEANBUFFERS
命令后运行任何查询,将使用物理读取将数据带回到缓存中,这很可能会比内存慢很多。同样,将此命令与
DBCC FREEPROCCACHE
-除非您完全知道自己在做什么,否则它不应在任何生产服务器上运行。这是一个有用的开发工具,因为您可以在性能测试环境中反复运行查询而无需由于内存中的数据缓存而导致的速度/效率的任何变化。
了解更多信息:http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/
#3 楼
我总是被告知要使用:dbcc dropcleanbuffers;
来自MSDN:
使用DBCC DROPCLEANBUFFERS使用冷缓冲区缓存测试查询
无需关闭并重新启动服务器。
要从缓冲池中删除干净的缓冲区,请首先使用CHECKPOINT生成一个冷缓冲区高速缓存。这将强制将当前数据库的所有脏页写入磁盘并清除缓冲区。完成此操作后,可以发出DBCC DROPCLEANBUFFERS命令从缓冲池中删除所有
缓冲区。
评论
另外:DBCC FREEPROCCACHE清除所有缓存的执行计划...
– marc_s
2011年11月28日在12:40
当然,仅当您要测试IO时...
– gbn
2011-11-28 12:44
#4 楼
编辑:OP的问题与缓存有关,并且使用诸如DBCC FREEPROCCACHE
之类的命令,该命令可清除存储的执行计划。显然我没有戴眼镜,因为我的回答是针对缓冲区的,也就是说,最近读取的数据存储在内存中以便快速检索。希望这对某人仍然有用。关于不运行
[DBCC DROPCLEANBUFFERS][1]
的原因,其他答案是正确的。但是,这样做也有两个原因:1:一致性
如果要比较两个不同的查询或过程,它们试图做同一件事他们可能以不同的方式浏览相同的页面。如果您天真地运行查询1和查询2,那么第二个查询可能会快得多,这仅仅是因为这些页面是由第一个查询缓存的。如果您在每次执行之前清除缓存,它们将从一个稳定的起点开始。
如果您确实想测试热缓存的性能,请确保多次运行查询,交替执行,并丢弃第一个查询几次运行。平均结果。
2:最坏情况下的性能
假设您有一个查询,对热缓存的查询花费一秒钟,而对冷缓存的查询则花费一分钟。一项优化可使内存中查询慢20%,但使IO绑定查询快20%,这可能是一大胜利:在正常情况下,没有人会关心额外的200毫秒运行时间,但是如果某种原因迫使查询执行在磁盘上运行,耗时48秒而不是60秒。
这对于拥有数十GB内存,相对较快的SAN和SSD存储的现代系统来说,并不是什么大问题。如果某些分析人员针对您的OLTP数据库运行大型表扫描查询,这会消耗掉一半的缓冲区高速缓存,那么存储效率高的查询将使您更快地恢复速度。
评论
感谢您将不同的建议合并为一个统一的答案。
–乔尔·克里斯托弗(Joel Christophel)
20年4月29日在22:10
@MartinSmith:好点!尽管您可以将我的注意力吸引到他们的确切要求上,但是我将进行编辑以澄清这一答案,尽管该答案可能与OP的特定问题无关。
–万事通
20年4月30日在14:48
评论
运行DBCC FLUSHPROCINDB时出错:向DBCC语句提供了错误的参数数量。
–辛
17-3-22在1:41
最后找到它:DECLARE @myDb AS INT = DB_ID(); DBCC FLUSHPROCINDB(@myDb);从这里开始:stackoverflow.com/questions/7962789/…
–汉斯·冯(Hans Vonn)
19-6-25在20:31