缓存SQL执行计划

Question

我知道SQL Server 2005会执行一些执行计划缓存，但这是否足以在同一个查询运行两次之间创建小时差异？下次需要1分钟第一次需要3个小时？这甚至可能吗？

Answer 1

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

如果你这样做

SET STATISTICS IO ON

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

3小时似乎很长，也可能是因为阻塞/锁定，陈旧的统计数据等

Answer 2

NO！没机会！

区别在于其他地方！
提出查询计划的时间最多只有几秒钟（更糟）。

很可能，差异是由于：

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

提到的差异： 3小时，大约1分钟左右是如此激烈，以至于我认为单独缓存数据无法解释。 这是有关查询的更多信息将有助于...的地方 例如，即使它是非常相同的查询运行两次，它第二次可能有不同的行为（例如，如果这是更新/插入/删除类型查询，它可能不会需要修改这么多行）。即使是仅SELECT查询也可能以不同方式运行，因为基础数据已被修改（通过其他查询/进程）。

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

• （静态地）检查执行计划本身。看看那里确实有什么东西可能会像3小时一样昂贵。
• 使用“statistics on”重新运行查询，并在每次运行之前清除（或不清除）缓存。

清除缓存的语句是（对于较新版本的SQL-Server，可能还有其他方法可以这样做）：

dbcc freeproccache
go
dbcc dropcleanbuffers
go

Answer 3

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

查询的第二次运行（“热运行”）仅使用缓存中的数据，当然要快得多。

然而，即使是最大的缓存，3个小时也足以填充，所以情况几乎不可能。

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

Answer 4

没有。很可能是您的查询第一次被阻止（例如，通过另一个会话或增长事件），而第二次则不是。

举例说明：INSERT INTO Table (Field) VALUES (1)。简单的查询，但是当你第一次运行它时，数据库已满并且必须增长。数据库为750GB，默认增长率为10％，因此必须创建75GB，因为SQL Server服务帐户未被授予Perform Volume Maintenance Tasks，因此增长持续约30分钟。然后再次运行查询，只需不到一秒钟。

这里指的不是您在执行期间发生过增长事件。重点是，如果查询持续3个小时，您需要了解为什么。 Activity Monitor是一个很好的开始。阅读像Performance Tunning Wait Queues这样的白皮书会更好。