SQL Server 2005 缓存

Posted 2023-05-08

【中文标题】SQL Server 2005 缓存

【英文标题】：SQL Server 2005 Caching

【发布时间】：2009-11-23 16:31:14

【问题描述】：

据我了解，SQL Server 2005 会进行某种结果或索引缓存。我目前正在分析复杂的选择语句，这些语句需要几秒钟到几分钟才能完成。我的问题是，即使我不更改它，第二次运行查询也不会花费超过一秒钟的时间。我目前正在使用 SQL Server Management Studio Express 对 SQL Server 2005 服务器执行查询。

我的问题是，有什么方法可以避免或清除导致我的查询在第二次运行时如此快速执行的缓存？

【参考方案1】：

这里有几个不同的事情可以发挥作用，最初想到的 3 个（按可能的顺序）如下 - 如果您需要一些帮助来解释结果，请按照以下说明进行操作并粘贴问题中的统计输出：

您的查询/批处理需要很长时间来编译执行计划。执行计划已确定并缓存（请参阅this post on serverfault 了解了解它们的时间长短、何时重建等） 要验证这一点，请打开statistics time output，它将为您提供有关引擎生成查询计划所需时间的信息。对于有问题的查询/批次：
DBCC FREEPROCCACHE SET STATISTICS TIME ON 执行批处理，捕获统计输出 再次执行批处理，捕获统计输出 比较 2 个统计输出，特别注意 2 个执行之间的解析/编译时间差异。
如果这是问题所在，您可以采取几种方法来解决问题，包括specifying a plan guide、指定static plan with use plan，或者可能还有其他选项，例如创建计划作业以每隔几分钟简单地编译一次计划（在 Sql 2k5 上的选项不如其他选项好）。 您的查询/批处理涉及大量数据 - 在第一次执行时，数据可能不在 buffer pool 中（基本上是服务器需要的缓存数据页），并且查询正在执行物理 IO 操作，而不是逻辑 IO 操作（即从磁盘读取与从缓存读取）。 要验证这一点，请打开 statistics io output，它会为您提供有关 IO 类型以及引擎为批处理执行多少个 IO 的信息。对于有问题的查询/批次：
DBCC DROPCLEANBUFFERS SET STATISTICS IO ON 执行批处理，捕获统计输出 再次执行批处理，捕获统计输出 比较 2 个统计输出，特别注意 2 个执行之间的物理/预读和逻辑 IO 输出。
要解决此问题，您基本上只有一个选项 - 优化相关查询，使其执行更少的 IO 操作。您可以考虑创建一个定期运行查询的计划作业，以将数据保留在缓冲池中，但这不是一个好的选择。 您的查询/批处理执行计划不佳和/或针对不同变量值的执行计划选择不佳 - 这是使用参数化语句的批处理/查询（即您在 where 中使用变量/静态值/join 子句？）？如果是这样，您是否看到相同值或不同值的执行时间差异？如果对于相同的值，答案可能是 #1 或 #2 - 如果对于不同的值，这可能是您的问题。如果您在研究 #1 和 #2 后认为这是问题所在，请使用 .sqlplan、TSQL 和您正在使用的不同参数值重新发布。

【讨论】：

感谢您提供详细信息。我绝对可以从这里弄清楚。

【参考方案2】：

我发现用于性能调整的唯一可靠指标来自 SQL Server 的 Profiler 应用程序。在查看 CPU 时间，尤其是读取时，您会更加远离“其他影响”。

例如，操作系统繁忙或多个用户处于活动状态会减少您的 CPU 份额，从而增加执行时间。而且您可能会或可能不会在多个 CPU 上获得并行性。但无论哪种方式，总 CPU 时间（相对于执行时间）将保持大致相同。

【参考方案3】：

这样做：

CHECKPOINT
DBCC DROPCLEANBUFFERS