我们的 C#/LINQ to EF 代码中有一个查询在通过我们的 Web 应用程序 (ASP.NET MVC) 运行时始终导致超时。
错误信息:
Execution Timeout Expired.
The timeout period elapsed prior to completion of the operation or the server is not responding.
直接在 SSMS 中运行由 LINQ 生成的 SQL 几乎是即时的，无论返回或查询的数据有多大(我们在查询中使用日期范围)。
This answer解决了超时问题:我们跑了
exec sp_updatestats
在数据库上，现在不再发生超时。
但是，正如评论中提到的那样，这是否解决了实际问题？
它是否可以防止问题在未来发生？
由于查询没有导致直接在 SSMS 中运行的任何问题，这是否表明 ASP.NET/EF 存在问题？
或者维护计划是正确的方法吗？我对维护计划一无所知。我看问题about rebuilding indices 、备份等。如果我需要一个维护计划来防止将来发生此超时问题，我必须设置什么类型的计划？
最佳答案
我首先要提到的是，包括更新统计信息和/或索引重组在内的定期数据库维护是最佳做法。这可以通过维护计划来实现，即流行的 Ola Hallengren's SQL Server Maintenance Solution ，或您自己的脚本。 Ola 的解决方案根据阈值有选择地执行维护以避免不必要的开销。SQL Server 使用基于成本的优化器，因此从统计数据中收集的更准确的行计数估计将有助于提供最佳的执行计划。
SSMS 和应用程序代码之间的查询性能明显不同表明执行计划不同。至于为什么同一查询的计划可能不同，我建议您仔细阅读 Erland Sommarskog 的文章 Slow in the Application, Fast in SSMS了解详情。不同计划的常见原因包括不同的 session SET 选项或参数嗅探，如本文所述。另外请注意，您需要使用参数化的 sp_executesql 查询来执行 SSMS 查询，以更好地模拟 EF 执行的参数化查询。 SSMS 中的局部变量或文字与参数不同，可能会导致不同的计划。
当您运行 sp_updatestats 时，它不仅会更新统计信息，还会使缓存的执行计划失效，从而解决参数嗅探和过时统计信息的问题。 DBCC FREEPROCCACHE alone 将解决参数嗅探，这应该针对生产 OLTP 环境中的问题计划。
关于c# - 我是否需要维护计划来防止将来发生已知的 SQL Server 超时？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/47375600/