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

Question

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

“我有一个包含4个选择查询的SQL脚本。我每天使用它已超过一个月，但昨天同样的查询需要2个小时，我不得不中止执行。”

他的问题是

• Q1。那天这个剧本怎么了？
• Q2。我怎样才能检查那些被执行的4个查询以及哪个查询中止的罪魁祸首？

我对Q2的回答是使用SQL分析器并检查Sql语句事件的跟踪。

对于Q1：我向他提出几个问题

1. 当天的数据量是多少？他的回答是：没有改变
2. 索引是否有任何变化，即某人可能已经删除了索引？他的回答是：没有改变
3. 是否通过检查数据管理视图来跟踪它是否陷入僵局？他的回答：不是陷入僵局

你还认为我还应该考虑什么？可以有任何其他原因吗？

由于我没有看到查询所以我无法将其粘贴到此处。

Answer 1

要看的东西（SQL Server）：

1. 统计数据已过期？有人运行大型批量插入操作吗？运行update statistics。
2. 索引的变化？如果是，如果是存储过程，请检查执行计划和/或重新编译...然后再次检查执行计划并更正任何问题。
3. SQL Server缓存执行计划。如果查询是参数化的或使用if-then-else逻辑，则第一次运行时，如果参数是边缘情况，则缓存的执行计划对于普通执行可能效果不佳。你可以阅读更多关于这个...啊...功能： 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 SQL poor stored procedure execution plan performance - parameter sniffing

Answer 2

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

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

Answer 3

• Use EXPLAIN分析四个查询。这将告诉您优化器将如何使用索引（或不使用索引）。
• 在脚本之间向SELECT NOW()添加查询，以便您可以测量每个查询所花费的时间。您也可以让MySQL为您做算术，将NOW（）存储到会话变量中，然后使用TIMEDIFF()计算语句的开始和结束之间的差异。

  SELECT NOW() INTO @start;
  SELECT SLEEP(5); -- or whatever query you need to measure
  SELECT TIMEDIFF(@start, NOW());

• @Scott在他的评论中建议使用slow query log来衡量长时间运行查询的时间。
• 一旦确定了长时间运行的查询，请在执行查询时使用查询PROFILER，以确切了解它花费时间的位置。