如何研究为什么每天运行2分钟的sql脚本需要2小时？

Question

我的同事今天问了我一个问题

“我有一个包含4个select查询的SQL脚本。我已经每天使用它一个多月了，但是昨天同一个查询花了2个小时，我不得不中止执行。”

他的问题是

• Q1。那天这个剧本怎么了？
• Q2。我如何检查这4条查询中哪些被执行了，哪一个是因中止而被执行的？

我对Q2的回答是使用SQL并检查跟踪是否为statement事件。

关于Q1:我很少问他问题

1. 那一天的数据量是多少？他的回答是:没有变化，。
2. 索引中是否有任何变化，即有人可能已经放弃索引？他的回答是: No
3. 它是否通过检查数据管理视图来跟踪它而陷入死锁？他的答案是:不是死锁。

你觉得我还应该考虑问什么？还有什么别的原因吗？

因为我没有看到查询所以我不能在这里粘贴它。

Answer 1

要查看的内容( Server)：

1. 统计数据过时了吗？有人运行过大容量插入操作吗？运行update statistics。
2. 索引的改变？如果是这样的话，如果是存储过程，检查执行计划和/或重新编译it...then，再次检查执行计划，并纠正任何问题。
3. Server缓存执行计划。如果您的查询是参数化的，或者使用If -然后-else逻辑，那么当它第一次运行时，如果参数是边缘情况，那么缓存的执行计划对于普通的执行可能会工作得很糟糕。您可以在以下网站上阅读有关this...ah...feature的更多信息：

- [http://www.solidq.com/sqj/Pages/2011-April-Issue/Parameter-Sniffing-Problem-with-SQL-Server-Stored-Procedures.aspx](http://www.solidq.com/sqj/Pages/2011-April-Issue/Parameter-Sniffing-Problem-with-SQL-Server-Stored-Procedures.aspx)
- [http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/88ff51a4-bfea-404c-a828-d50d25fa0f59](http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/88ff51a4-bfea-404c-a828-d50d25fa0f59)
- [SQL poor stored procedure execution plan performance - parameter sniffing](https://stackoverflow.com/questions/1007397/sql-poor-stored-procedure-execution-plan-performance-parameter-sniffing)

​

Answer 2

在这种情况下，我的方法是：

1. 情况是这样的，他不得不中止执行，因为查询所花费的时间比预期的要多，最后它没有完成。根据我的理解，您正在查询的表可能存在任何阻塞会话/未提交事务(由任何不同的用户在当天执行)。因为您正在执行'select‘语句，而且我知道，'select’语句用于等待任何其他事务的完成(如果在‘select’之前执行的事务)。您的查询可能正在等待任何其他事务的完成(事务可能有更新/插入或删除)。检查阻塞会话(如果有的话)。
2. 对于单个会话，sql服务器在线程之间切换。您需要检查包含查询的线程是否处于“挂起”/“运行”或“运行”模式。在这种情况下，查询可能处于挂起模式。调查查询的模式和原因。
3. 接下来就是碎裂。最佳实践是在您的环境中配置索引重建/重组作业，这有助于消除不必要的碎片。这样，在返回数据时，查询就需要扫描较少的页面。否则，查询将花费越来越多的时间返回数据。配置作业并每周至少执行作业一次。它将不断刷新您的索引和页面。

Answer 3

• 使用解释来分析这四个查询。这将告诉您优化器将如何使用索引(或不使用索引)。
• 在语句之间将查询添加到SELECT NOW()脚本中，这样您就可以度量每个查询所用的时间。您还可以让MySQL为您做算术，方法是将NOW()存储到会话变量中，然后使用TIMEDIFF()计算语句的开始和结束之间的差异。 选择NOW()入@start；选择睡眠(5)；--或任何您需要度量的查询，选择TIMEDIFF(@start，NOW())；
• @Scott在他的评论中建议，使用慢速查询日志来度量长期运行查询的时间。
• 一旦您确定了长期运行的查询，在执行查询时使用查询轮廓仪来查看它在哪里花费的时间。