我有一个在IIS7上运行的ASP.NET MVC-4，Entity Framework 5应用程序，带有SQL Server 2012数据库。
每天，在7:45到8:15之间，数百名用户执行相同的日常日常任务。而且表现非常糟糕。我们到处都是超时的。
所以今天我坐着看几个诊断工具。在SQL Server Profiler上，我看到数百个查询在30秒后超时。我复制了查询并将其放入SQL Sentry中以查看查询计划中发生了什么。 30分钟后，查询终于执行了，显示了一个完全无懈可击，效率低下的执行计划。索引扫描返回了数千万条记录，这些记录应该通过较早的连接过滤到数十，甚至数百条记录。
与此同时，我正在检查性能监视器以获取其他诊断信息。 CPU正在以20-30％的舒适度巡航，我们有256 GB的RAM，其中大约200个为SQL Server保留，并且不缺乏工作内存。没有重要的数据库锁定，没有死锁。只是可怕，可怕的表现。
所以后来我尝试运行完全相同的查询。它在大约0.1秒内回来了。查询计划看起来完全不同：一切都是索引搜索，细线和一切。我在SQL事件探查器中捕获的每个其他查询在7：45-8：15之间花了5秒多的时间，现在又以0.1秒的速度返回。
我们在同一时间窗口内每天都遇到同样的问题。我该如何解决此问题？我认为在不同时间执行查询时，不同的查询计划可能会有一些线索;这可能与SQL统计数据有关吗？如果是这样，我们如何解决它？
编辑：我接受了@ t_m的建议并部署了一个DMV脚本。现在，我可以确定查询超时时遵循的执行计划，以及它工作时遵循的计划。