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.

线程A等待线程B的数据，线程B等待线程A的数据，互相等待，就会陷入阻塞，这也是一种线程阻塞。阻塞状态是正在运行的线程遇到某个特殊情况。例如，延迟、挂起、等待I/O *** 作完成等。进入阻塞状态的线程让出CPU，并暂时停止自己的执行。线程进入阻塞状态后，就一直等待，直到引起阻塞的原因被消除，线程又转入就绪状态，重新进入就绪队列排队。

增加线程缓存大小

连接管理器线程处理服务器监听的网络接口上的客户端连接请求。连接管理器线程将每个客户端连接与专用于它的线程关联，该线程负责处理该连接的身份验证和所有请求处理。因此，线程和当前连接的客户端之间是一对一的比例。确保线程缓存足够大以容纳所有传入请求是非常重要的。

MySQL提供了许多与连接线程相关的服务器变量：

线程缓存大小由thread_cache_size系统变量决定。默认值为0（无缓存），这将导致为每个新连接设置一个线程，并在连接终止时需要处理该线程。如果希望服务器每秒接收数百个连接请求，那么应该将thread_cache_size设置的足够高，以便大多数新连接可以使用缓存线程。可以在服务器启动或运行时设置max_connections的值。

还应该监视缓存中的线程数（Threads_cached）以及创建了多少个线程，因为无法从缓存中获取线程（Threads_created）。关于后者，如果Threads_created继续以每分钟多于几个线程的增加，请考虑增加thread_cache_size的值。

使用MySQL show status命令显示MySQL的变量和状态信息。这里有几个例子：

Monyog线程缓存监测

Monyog提供了一个监控线程缓存的屏幕，名为“线程”。与MySQL线程相关的服务器变量映射到以下Monyog指标：

Monyog线程屏幕还包括“线程缓存命中率”指标。这是一个提示线程缓存命中率的指标。如果值较低，则应该考虑增加线程缓存。在状态栏以百分比形式显示该值；它的值越接近100％越好。

如果这些指标的值等于或超过指定值，则可以将每一个指标配置为发出警告和/或严重警报

---