加载中…MySQL大量线程处于waittingfortableflush状态
(2020-03-27 22:23:16) | 分类： MySQL |
背景：
某核心实例出故障，业务反馈SQL无法响应，已经严重影响到业务了！运维火速登上DB查看，发现大量线程处于waitting for
table flush状态，对tDeal表的SQL操作被堵住了，如下：
分析：
线程处于waitting for table flush状态，这代表什么呢？
（1）、这个状态表示的是：要对表做flush操作，但是一直处于等待状态，无法flush；
（2）、出现waitting for table flush状态的可能情况是：有一个flush
tables命令被别的语句堵住了，而它又堵住了我们的select语句。从上图我们确实看到，很多select语句处于waitting
for table flush状态；
（3）、在MySQL里面，对表做flush操作的用法，一般有：
a、flush tables;
b、flush tables with read lock;
c、flush tables t with read lock;
如果指定表t，则代表只关闭表t;如果没有指定表名，则flush操作会关闭所有打开的表；
（4）、从第二点的分析，flush tables命令被别的语句堵住了，然后flush
tables命令又堵住了后续的select。那么这里我们就需要找到，到底是哪些SQL堵住了flush
tables，如果能找到，将这些SQL进行kill，那么问题就迎刃而解；
处理过程：
（1）、过滤掉处于waitting for table
flush状态和sleep状态的线程，最后可以看到以下一直在执行中的select语句：
（2）、跟业务确认过可以kill这两个SQL，于是快速kill这两个线程。不一会，业务就恢复了，处于waitting for
table flush的语句都正常执行，不再被阻塞；
复盘：
（1）、由前面的分析思路，我们还没有找到flush table的语句，那么这个语句是否被执行过，是谁执行的呢？
（2）、为了能找出这个语句，我直接查看binlog，发现在故障开始时间段，确实有flush tables的语句：
a、FLUSH TABLES;
（3）、查看慢日志，并进行过滤，终于找到执行flush tables的账号和来源IP，并且发现慢日志里面执行了两个flush
table的操作：
a、FLUSH TABLES;
b、FLUSH TABLES WITH READ LOCK;
原因分析：
（1）、对表的select的SQL语句执行时间长，这期间表一直被处于打开状态，而后flush
tables命令要去关闭表，就需要等select语句查询结束；
（2）、由于select语句迟迟未结束，就导致flush tables指令一直处于等待状态；
（3）、后续进来的select查询被flush指令堵住了，导致大量线程处于waitting for table
flush状态。
喜欢
0
赠金笔