我应该刷新查询计划缓存吗

Question

请让我解释一下我的问题和情况：

我有一个 Web 应用程序 - MVC3、MSSQL Server 2005、LinqToSQL。它一直运行良好，直到一个晴朗的早晨，我将很多行推送到一个经常使用的表中，从那时起我就遇到了查询超时。为了解决这个问题，我运行了 Database Tuning Advisor 并添加了一些索引和统计信息。我还创建了一个维护计划来每天重建索引。这些添加后，应用程序一直表现不稳定；它会快速工作几个小时，然后它会再次开始超时。接下来，生活迫使我清理表格，现在其中的行数比以前更少，但超时仍在发生。所以，我删除了我创建的所有索引，现在网站更加稳定，但有时我仍然会看到一些超时。

我一直在试图弄清楚如何修复这些查询，当我对其进行分析并将查询直接粘贴到 SQL Management Studio 时，它会在 1 秒内返回结果，但是当我从我的应用程序运行此查询时，大约需要 25 秒. 然后在它第一次运行后，下次它会像在服务器上一样快！

我开始做一些研究，看起来当我使用所有这些索引时，我的查询计划搞砸了，现在它们正在产生问题。

我的问题是：

1. 我是否应该刷新我的查询计划缓存（大约 22000 个查询 - 其中很多只使用过一次）并且
2. 如果我这样做，对 SQL 都在重建时会产生什么影响？

Answer 1

让我们逐步解决您的问题：

它一直运行良好，直到一个晴朗的早晨，我将很多行推送到一个经常使用的表中，从那时起我就遇到了查询超时。

每当您对表进行大量更新/插入时，强烈建议更新统计信息和重组/重建索引。这样查询优化器不会根据错误的估计选择或产生错误的计划。

为了解决这个问题，我运行了 Database Tuning Advisor 并添加了一些索引和统计信息。

在不了解您的工作量并正确测试建议的情况下，切勿这样做。请参阅不要盲目地创建那些“缺失”的索引！通过亚伦伯特兰。

我还创建了一个维护计划来每天重建索引。

我建议您查看索引的碎片率，并相应地重新组织或重建它们。最好是使用SQL Server 索引和统计维护，因为它是最好的免费软件，并且被广泛实施。

接下来，生活迫使我清理表格，现在其中的行数比以前更少，但超时仍在发生。所以，我删除了我创建的所有索引，现在网站更加稳定，但有时我仍然会看到一些超时。

和上面一样。现在优化器有错误的统计数据，因此可以生成低效的查询计划。最好是更新统计信息并使用 标记该表以进行重新编译sp_recompile，因此下次优化器将根据可用的更新统计信息生成新计划。

另请阅读：应用程序速度慢，SSMS 速度快？

Answer 2

首先，不，您可能不应该清除查询计划缓存。您可能在参数嗅探方面遇到问题。这里有一些关于它的文章。 Greg Larson 与 SimpleTalk、Jes Schultz Borland 与 Brent Ozar Unlimited以及Thomas LaRock。你可以快速搜索，你会看到很多其他的。这是一个热门话题。

如果我是你，我会做的第一件事是更新每个受影响表的统计信息。

update statistics TableName;

接下来对受影响的表运行 sp_recompile。这将重新编译与该表关联的所有存储过程。这会产生一些影响（我稍后会解释），但比清除整个缓存要好。

EXEC sp_recompile Table;

当您清除查询计划缓存或标记存储过程以进行重新编译时，优化器必须为该段代码重新创建计划。这当然需要时间。如果你有一个活动系统，完全清除你的缓存会在一段时间内降低整个系统的速度，同时重新创建一切。当然，每个查询/SP 只会在使用时重新创建。