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

我：发生什么事情了？

开发同事：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进行优化。搞定！

     本文转自andylhz 51CTO博客，原文链接：http://blog.51cto.com/andylhz2009/1354890，如需转载请自行联系原作者