Mysql线程大量Wating For table flush问题分析

早上8点种线上服务器大量报出以下异常

show processlist后发现大量线程处于Wating For table flush状态

官方文档对Waiting for table flush状态的解释

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

以下场景会导致线程处于Waiting for table flush状态

1 线程执行 FLUSH TABLES，等待其他线程关闭相应flush的表。

2 其他线程执行如 FLUSH TABLES tbl_name, ALTER TABLE..等 *** 作，该线程也需要等相应的表关闭。

session1 在t1时间查询表t1,这里模拟一个慢查询。

session2 在t2时间flush table t1

session3 在t3时间查询表t1.

show processlist看下现在三个线程状态

可以看到由于慢查询导致t1表没关闭，后面的flush table等待，然后导致所有查询t1表的线程都会处于Wating for table flush状态。

经过和DBA复盘整个流程，DBA定时执行Dump备份，而Dump命令会导致flush tables,由于这个时候慢sql还没有执行结束，所以导致flush table等待，从而导致后续sql也处于waiting for table flush.

官方版本测试到8.0.21依旧存在这个问题，Percona已经修复了，修复如下

https://www.percona.com/blog/2018/03/27/analyze-table-is-no-longer-a-blocking-operation/

能力有限简单记录。

问题如下：

乍一看来，很是奇怪，这里没有出现我们经常遇到的flush table/flush table with read lock 堵塞，直接出现了 Waiting for table flush的堵塞，有点像

https://www.jianshu.com/p/b141585cd844

以前记录的文章中的案例2，但是其实并不一样，这里是由于analyze table语句造成的。构造非常简单（必须是社区版本，我使用的8.0.21），如下：

此时堵塞的情形就是Waiting for table flush

analyze table 除了更新我们的统计数据，实际上最后做了一个 *** 作如下（栈）：

大概看一下做了什么，如下：

这里判断了是否当前table share正在使用，如果正在使用（很显然我们这个table share是不能直接释放的，因为有select一直持有它）那么将share版本的设置为0（share->clear_version()，实际上这个版本由全局变量refresh_version初始化），目的在于下次如果有使用表定义的时候需要重新打开table share。然后释放了当前没有使用的table cache（类型TDC_RT_REMOVE_UNUSED），如下：

当再次访问表的时候（open_table），会去判断如下是否有老的table share存在，如果存在则需要等待释放：

首先如果存在判断是否存在的老版本，判断是通过table share的版本和当前全局版本refresh_version进行比对，前面我们知道这里table share的版本已经设置为0，因此这里必然进入release_table_share环节，然后等待持有者的释放（案例窗口1的select查询），然后再次获取table share。等待栈如下：

进入waiting for table flush状态

Percona在上文中已经提到问题如下：

一个关键的修改点如下

官方版本：

Percona版本：

如此修改后analyze不会进入tdc_remove_table函数，那么table share的版本不会设置为0。因此如果使用官方版本小心本问题。

---