SQL 执行计划缓存答案

【问题标题】：SQL execution plan cachingSQL 执行计划缓存
【发布时间】：2012-02-18 02:12:41
【问题描述】：

我有几个关于 Microsoft SQL Server 2008 性能的问题，主要是关于执行计划。

据MSDN 称，与直接SQL 查询相比，存储过程具有更好的性能，因为：

数据库可以准备、优化和缓存执行计划，以便以后可以重用执行计划。

我的第一个问题是为什么会这样。我之前读过，在使用参数化查询（准备好的语句）时，执行计划被缓存以供后续执行可能具有不同的值（执行上下文）。存储过程仍然会更有效吗？如果是这样，存储过程的执行计划是仅按需重新创建，还是不太可能从缓存中清除？参数化查询是否被视为ad-hoc query，意味着执行计划更有可能从缓存中清除？

另外，由于我还是这个领域的新手，我想知道是否有某些命令只能在 T-SQL 中使用。在 Microsoft SQL Management Studio 和 ADO.NET 中，我有一个查询在第一次运行时需要大约 12 秒才能完成，之后大约需要 3 秒。作为我的演示文稿的一部分，该查询应该是无效的。问题是，在我的查询中，我根据this article 和OPTION (RECOMPILE) 同时使用CHECKPOINT 和DBCC DROPCLEANBUFFERS。但是，至少前两个似乎没有什么区别，因为查询仍然需要 3 秒。我的猜测是，这是由于数据缓存没有被清除。为什么缓存似乎没有被清除的任何想法，或者关于为什么我的查询在第一次执行后明显更快的任何想法？

这些是我现在能想到的问题。

【问题讨论】：

好问题 - 我会将这篇文章分成几篇文章，一篇关于存储过程与参数化查询的问题，一篇关于多次运行查询等的文章
也许你是对的；我的想法是不要发送垃圾邮件。 :-)
stackoverflow 的想法是让问题保持集中，这样答案也可以集中起来——所以不用担心会在网站上加载一堆问题
计划缓存可能很棘手。我不记得这个链接，但我记得的一点是，完全限定所有列引用会增加重用的机会——我经常因为没有这样做而感到内疚。参数化也可以提高重用性。
以防万一你以前没有看过这个讨论 - stackoverflow.com/questions/59880/…

标签： sql sql-server caching

【解决方案1】：

“存储过程会更高效吗？”：基本上不会。它节省的很少。从性能的角度来看，您几乎可以在您的应用程序中使用 SQL 文字（除非它们非常庞大）。 SQL Server 会将您发送给它的字符串匹配到一个缓存计划就好了。

“我有一个查询在第一次运行时需要大约 12 秒才能完成，然后在大约 3 秒后” 考虑到您清除了所有缓存，这可能是一个统计问题。 SQL Server 会在您第一次访问列时自动创建统计信息。我想这就是你曾经发生过的事情。尝试运行 sp_updatestats（在清除缓存之前）。

【讨论】：

您知道存储过程和参数化查询的执行计划是否在缓存中以相同的方式“处理”？我的意思是如果一个人比另一个人更有可能被冲走。清除统计信息似乎没有太大效果。
我不认为它们有不同的冲洗特性。刷新仅在内存不足时发生，所以这对你来说可能根本不重要。
出于性能原因将所有代码保留在存储过程中确实有点过时了。