【发布时间】：2018-05-02 16:52:48
【问题描述】：
我们的 C#/LINQ to EF 代码中有一个查询，该查询在通过我们的 Web 应用程序 (ASP.NET MVC) 运行时始终导致超时。
错误信息：
执行超时已过期。
在操作完成之前超时时间已过或服务器没有响应。
直接在 SSMS 中运行由 LINQ 生成的 SQL 几乎是瞬时的，无论返回或查询的数据大小如何（我们在查询中使用日期范围）。
This answer 解决了超时问题：我们跑了
exec sp_updatestats
在数据库上，现在不再发生超时。
但是，正如 cmets 中提到的，这是否解决了实际问题？
它是否可以防止问题在未来发生？
由于查询没有导致直接在 SSMS 中运行的任何问题，这是否表明 ASP.NET / EF 存在问题？
或者维护计划是正确的方法？我对维护计划一无所知。我看到问题about rebuilding indices、备份等。如果我需要维护计划来防止将来发生此超时问题，我必须设置哪种类型的计划？
【问题讨论】：
-
回答：没有。在我作为许多不同平台上的开发人员的漫长职业生涯中，我了解到您永远不应该通过更改设置/配置等来解决超时问题。唯一安全的事情是：减少您在一次调用中尝试完成的工作量。
-
@GertArnold 我想听听更多，为什么不呢？在我的情况下，我每天凌晨 2:00 运行更新所有统计信息
sp_updatestats的工作，有时需要 1 小时才能完成，但第二天所有用户都很满意，数据库大小（30GB +） -
@GertArnold - 感谢您的洞察力。我可以使用什么方法来优化我的查询 - 或减少我在其中所做的工作量？有问题的查询并不比我们经常做的其他事情复杂。仅当我们在特定日期范围内查询数据时才会发生超时。具有不同日期范围的相同查询不会产生超时。我们如何处理这些信息？
-
@Monah 当然，每个数据库都需要维护计划（统计、索引碎片整理/重建）。我们将答案中提到的相同脚本应用于客户的数据库。但这是为了防止在内置机制不够用时逐渐退化（他们很难做到）。这不是与不断重复的超时作斗争。然后是从根本上解决问题的时候了：减少任务规模、改进索引和/或查询、重组数据，或者，作为最后的手段，购买更好的硬件。
-
@Winks 在不知道数据的情况下很难判断。也许某些日期范围会导致在表格的物理分散部分进行搜索。您可能需要重新评估其聚集索引：use-the-index-luke.com/blog/2014-01/…
标签： c# asp.net sql-server linq maintenance-plan