MySQL 优化脚本(analyze)引起的使用溃散51CTO博客 - 娱乐之横扫全球

MySQL 优化脚本(analyze)引起的使用溃散51CTO博客

2019年04月26日11时42分06秒 | 作者: 浩邈 | 标签: 优化,脚本,履行 | 浏览: 666

早上刚走进公司的门口,快走到办公桌的时分,开发的搭档很着急的跟我说:你可来了!

我:发作什么事情了?

开发搭档: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进行优化。搞定!

















版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表娱乐之横扫全球立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章