系统环境
mysql5.6.46一主一从
navicat12.2
问题现象
从备库上通过navicat查询几张业务表时，长时间没有反应，通过limit 限制几条返回记录也是同样的结果，查询其他业务表则没有该问题，通过show processlist的问题现象如下：
1、两条SQL语句执行了6多万秒，状态处理sending data，
2、对几张业务表执行的查询语句显示的状态为Waiting for table flush
3、一个语句处理刷新系统日志状态（遗憾详细信息没记录下）
解决方法
1、对于问题现象3，应该是xtrabackup备份导致的
这里在服务器查看备份脚本，发现正在运行，但备份文件的大小一直没有增长且和前一天的备份大小一致(画外音：最近两天没新增数据)，这时对该备份进程进行了kill了，同时也对processlist里的线程进行kill了，接着查询哪几张业务表还是有相同的问题
2、对状态为Waiting for table flush的查询语句进行kill
执行完成后还是有同样的问题
3、查看打开的业务表show open table where in_use>=1
±---------±------±-------±------------+
| Database | Table | In_use | Name_locked |
±---------±------±-------±------------+
| test | a | 3 | 0 |
| test | b | 1 | 0 |
| test | c | 2 | 0 |
| test | d | 1 | 0 |
±---------±------±-------±------------+
发现这几张还是在使用，当时就在想能不能通过工具查看这些表被哪些线程对应的SQL语句使用，还真这样的工具inntop，后面单独写一篇。
这里一共就可以十几在语句，很容易就找到那两条SQL语句了，即问题现象1，查看后还是SQL语句执行效率的问题，先kill掉两条SQL语句后，问题就是解决了
总结
1、SQL语句执行效率低导致的查询阻塞问题
2、什么情况下会出现Waiting for table flush呢，怎么避免呢
3、对上面的现象进行复现
4、出现问题后没有将详细信息存档，写博客时才发现材料不足
参考文档
附件
Waiting for table flush
The thread is executing FLUSH TABLES and is waiting for all threads to close their tables, or the thread got a notification that the underlying structure for a table has changed and it needs to reopen the table to get the new structure. However, to reopen the table, it must wait until all other threads have closed the table in question.
This notification takes place if another thread has used FLUSH TABLES or one of the following statements on the table in question: FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, or OPTIMIZE TABLE.
https://dev.mysql.com/doc/refman/5.6/en/general-thread-states.html
下一篇：专门测试Waiting for table flush