今天看了一个案例，自己在备库上做了一下。确实会引起很多问题。
1.一些慢SQL在运行
2.一个终端发出了flush tables命令
3.很多查询都被阻塞了

假设有两个慢SQL正在运行，这时发出的flush tables命令被阻塞，
但是后续的查询重新打开表，前提条件是所有的线程关闭表，但是慢SQL还在运行。
步骤1阻塞了步骤二,步骤二导致步骤三需要等待步骤一。

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, orOPTIMIZE TABLE.

大概的情况就是这样。
在主从读写分离的模式下，主库使用Xtrabackup备份，中间会有一个flush tables with read lock。
如果这个被复制到了从库，而不巧从库还有慢SQL，那么这个问题就很可能出现。
但是使用Xtrabackup备份是否复制flush tables,我还需要进一步实验。

实验如下:
终端一运行一个慢SQL

终端二也运行一个慢SQL

终端三运行flush tables,被两个慢SQL阻塞

终端四的普通查询被阻塞

终端五的普通查询被阻塞

查看上述终端的运行情况

参考:
http://blog.itpub.net/29254281/viewspace-1082297/
http://hidba.org/?p=421

ITPub博客

Waiting for table阻塞查询的问题

最新文章