MySQL 优化脚本（analyze）引发的应用崩溃

早上刚走进公司的门口，快走到办公桌的时候，开发的同事很着急的跟我说：你可来了！

我：发生什么事情了？

开发同事：XX数据库死掉了！

我：特别惊讶！这个库运行的一直的很好的，怎么会死掉了？何况也没有接收到监控的报警信息？

      别着急，等我远程链接上去看看。

登录到MySQL后查看一下状态： show processlist；

而后看到至少有一千多个查询一直在执行，根据以往的经验是有锁出现了，致使后来的查询被阻塞掉了，因此应用这边就崩溃了，返回了超时的错误！

仔细一看显示的单个SQL查询的状态大部分都是：.....Query26037Waiting for table flushSELECT.......

注意红色字体的关键字，官网的解释是：

Flushing tables

The thread is executing FLUSH TABLES and is waiting for all threads to close their tables.

也就是说线程执行刷新表操做而且等待全部的线程关闭他们占用的表。

一个超长执行时间的SQL被发现了，这个SQL大概执行了十几个小时尚未查出结果。

可是这样也不该该回引发flush tables 的问题出现。

kill 掉这个SQL线程以后，慢慢的系统恢复了正常查询的状态。

就这样粗暴的处理完成以后，就看系统各类的日志，开始查找缘由，忽然想到今天是周末

对呀周末！！

周末会怎样呢？

周末有一个优化脚本任务执行的！

这个优化脚本就是使用analyze去分析每张表，analyze会收集表的统计信息。

会致使mysql检测到对应的table作了修改，必须执行flush操做，close和reopen表

由此能够推断出，是由于那个执行时间超长的SQL在执行过程当中，个人优化脚本任务也启动了，对SQL占用的表进行了analyze 那张表就须要被close和reopen。可是SQL写的太烂，一直没有执行完成，也就不能释放对表的占用。以致于后面的SQL就要排队等待。

只要将那个SQL给kill掉就关闭了表，而后续的SQL就从新打开了那个表，正常！

我根据推断作了一个测试，首先手工执行那个烂SQL等待了一下子没有查出结果的迹象，在这个时候使用analyze table table_name;

show processlit 查看状态，果真如此！截图中红色框部分

实验证实了是analyze引发的问题，但不是主要的问题。

因而和开发商量须要改进SQL进行优化。搞定！