实体框架LINQ查询开始超时-在数据库服务器重新启动后再次加速

Question

这里有一个奇怪的例子。我们有一个使用EntityFramework连接到MS SQL Server数据库(SQL2010)的C# ASP.NET网站应用程序。我们最近遇到了一个例子，应用程序中的LINQ查询通常运行得非常快(< 2秒)，突然开始运行太长时间，导致连接超时。数据库大小或从查询返回的数据量没有显著变化。此外，当我们在SQL Mgmt Studio中运行SQL版本的查询时，它运行正常(快速)。

问题不会发生在我们的开发或登台数据库中，但当我连接到Visual Studio中的Prod DB并在调试模式下运行代码时，我会遇到同一查询的超时。作为一个测试，我对WHERE语句做了一个不应该影响查询逻辑的小改动(即:在末尾添加一行：'&& table.fieldname != "FOOBAR"')，然后查询正常运行(快速)。当我从WHERE语句中删除多余的无用行并再次运行时，它又回到了超时状态(来回尝试了几次)。

DBA尝试在DB上执行DROPCLEANBUFFERS，但没有效果。在分离过程中，我们重新启动了生产数据库服务器，这解决了这个问题(查询再次运行得很快)。

我知道EF和LINQ在DB服务器上缓存查询。基于以上内容，在我看来，这个查询的缓存版本不知何故被破坏了。我本以为DROPCLEANBUFFERS可以修复它，但似乎还有其他东西保存着通过重新启动而被清理/重置的查询信息，而不是通过DROPCLEANBUFFERS。

有没有其他人遇到过这个问题？有没有办法防止它呢？有没有比重启更简单的方法来刷新缓存的EF/LINQ查询？

顺便说一句，在使用常规存储过程拉取数据的应用程序的早期非EF/非LINQ版本中，同样的数据库也有类似的问题。每隔一段时间(一年2-3次)，通常在几秒钟内运行的某个so会启动超时，但仅当从应用程序运行时才会启动。直接从SQL Mgmt Studio执行的同一SP仍将正常运行。修复此问题的唯一方法是完全删除并重新创建SP。DBA的结论是，数据库为同一SP创建了两个执行计划，这是问题的根源(尽管我们从未确切了解发生这种情况的原因或如何防止)。

如有任何帮助或建议，我们将不胜感激！

Sascoaz

Answer 1

您的开发/临时服务器与生产服务器之间还有什么不同-是否在硬件资源不足的虚拟机上进行生产？

由于这在dev/staging中有效，并且我假设您的db结构在所有3个数据库上都是完全相同的，因此开始关注您的数据库之外的内容。

我可能只会评论，但我是一个菜鸟，没有stackoverflow mojo。