缓存SQL执行计划

SQL Server不仅缓存执行计划,还缓存数据

如果你愿意的话

将统计信息IO设置为打开

看看你将看到的输出 逻辑读 和 物理读 ,逻辑读取来自RAM,物理读取来自磁盘。因此,第一次看到物理读取的数字时,如果再次运行该数字,则应该看到逻辑读取的值。

3小时似乎很长,也可能是因为阻塞/锁定、过时的统计数据等。

理论上,当第一次运行(一个“冷运行”)时,查询所需的表和索引页可能位于磁盘上。查询获取了它们,引擎将它们放入缓存中。

查询的第二次运行(“热运行”)只使用缓存中的数据,当然这要快得多。

但是,3个小时甚至足以填充最大的缓存,因此这种情况很难实现。

最有可能的是,第二次运行中使用了另一个执行计划(可能是由于统计信息更新)。

不!不可能!

区别在其他地方!
提出查询计划的时间最多为几秒钟(更糟)。

很可能是由于以下两种原因造成的:

• 缓存数据
• 存在/不存在来自其他查询/进程的锁
• 第二次运行查询时的不同数据上下文(引用的行数较少的SQL对象等)

所提及的差异: 3小时,最短1分钟左右是如此的激烈,我不认为只有缓存数据才能解释它。 .
在那里有更多关于查询的信息会有帮助…
例如,即使它是 完全一样 查询运行了两次,可能在第二次时具有不同的行为(例如,如果这是更新/插入/删除类型的查询,则可能不需要修改这么多行)。即使是仅选择查询也可能以不同的方式运行,因为基础数据已被修改(由其他查询/进程)。

以下是一些了解更多信息的建议:

• 检查(静态)执行计划本身。看看里面是否真的有什么东西可能会花费3个小时。
• 使用“statistics on”重新运行查询,并在每次运行之前清除(或不清除)缓存。

清除缓存的语句有(对于较新版本的SQL Server,可能还有其他方法可以做到这一点):

dbcc freeproccache
go
dbcc dropcleanbuffers
go

不。很可能是第一次您的查询被阻塞(例如,被另一个会话或增长事件阻塞),而第二次没有。

要给出示例,请使用此查询: INSERT INTO Table (Field) VALUES (1) 。简单查询,但当您第一次运行它时,数据库已满,必须增长。数据库为750 GB,默认增长率为10%,因此必须创建75GB,因为未授予SQL Server服务帐户 Perform Volume Maintenance Tasks 因此,这种增长会持续大约30分钟。然后再次运行查询,所需时间不到一秒钟。

这里的要点并不是您在执行过程中有或没有发生增长事件。关键是,如果查询持续3小时,您需要了解 为什么? . Activity Monitor 是一个很好的开始。像读白皮书一样 Performance Tunning Wait Queues 会更好。