SQL执行计划在白天更改

时间:2014-02-25 11:44:34

标签: sql sql-execution-plan

当我在上午11点运行它时,我的查询永远不会完成(需要2小时以上),当我在晚上7点运行它时需要1分钟。显然,执行计划在白天发生了变化。是什么导致的?

数据不会改变。自动统计信息已关闭,统计信息和索引会在一夜之间重建。

我在客户端的环境中运行它,所以我无法确定还有什么使用相同的SQL服务器。所以这是我的主要关注点,我认为服务器被其他东西加载得太多,以至于无法处理我的查询。

我应该在服务器的哪些参数中查找问题的原因?

我还应该在哪里寻找问题?我还应该考虑哪些其他因素?

任何帮助都将受到高度赞赏。

更新:忘记提及我在同一时间(上午11点)运行了一大堆其他大查询,它们都运行正常。实际上我有7个查询在晚上运行良好,并且在早上没有完成。它们都使用相同的视图来连接相当大的表,这是失败的查询与不失败的查询之间的唯一区别。所以我想知道SQL服务器是否没有足够的内存或者某些东西来保存视图执行的中间结果,这就是查询永远不会完成的原因。

那么我应该监控服务器的哪些参数才能找到问题?

更新很遗憾,由于权限问题,我没有晨跑的执行计划

UPDATE 我不认为表锁是原因,因为我知道在服务器上使用我的数据库是什么,我可以在12点说运行相同的查询时没有其他任何东西从我运行side(即我的表上应该没有锁和未提交的事务)并且查询花费相同的时间。

1 个答案:

答案 0 :(得分:0)

很多事情都会影响到这一点。这真的是查询还是存储过程调用?我查询重新编译每次调用存储过程使用缓存计划。如果存储过程的参数可以提供截然不同的结果,那么您可以使用WITH RECOMPILE提示

如果你能忍受脏读,我会说:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

位于代码顶部。这将允许您的查询访问其他进程在锁定中保存的数据。风险在于,如果数据发生变化,您的答案可能不是100%正确。如果您的数据总是可以添加或者时间点值可以接受,那么这非常有效。

我会在晚上查看查询的执行计划并优化该查询,即使1分钟是可以接受的,也可能会上传大量您在晚上有能力但仍在早上竞争的数据