MySQL Flush导致的等待问题
tables 参数关闭所有打开的表，同时该操作将会清空查询缓存中的内容
FLUSH TABLES WITH READ LOCK 关闭所有打开的表，同时对于所有数据库中的表都加一个读锁，
直到显示地执行unlock tables，该操作常常用于数据备份的时候。
链接：http://wangqiaowqo.iteye.com/blog/1627985
前言
在实际生产环境中有时会发现大量的sql语句处于waiting for table.. 状态中，有时候看起来会让人觉得困惑，本文将讲解此状态产生的原因及解决办法。
正文
本文中用到了lock table来模拟实际情况， 首先介绍一个lock tables需要注意的事项，如果在一个session中使用了lock tables，那么在此session中将只能访问获取到lock的表。官方解释：
If the LOCK TABLES statement must wait due to locks held by other sessions on any of the tables, it blocks until all locks can be acquired.
A session that requires locks must acquire all the locks that it needs in a single LOCK TABLES statement. While the locks thus obtained are held, the session can access only the locked tables. For example, in the following sequence of statements, an error occurs for the attempt to access t2 because it was not locked in the LOCK TABLES statement:
Tables in the INFORMATION_SCHEMA database are an exception. They can be accessed without being locked explicitly even while a session holds table locks obtained with LOCK TABLES.
基于这样的原因，往往在备份时选择flush table with read lock;是个不错的选择，如果成功，它会锁住所有表。
Closes all open tables, forces all tables in use to be closed, and flushes the query cache. FLUSH TABLES also removes all query results from the query cache, like the RESET QUERY CACHE statement.
模拟Flush操作导致的waiting tables等待问题。
a) 在终端1中执行lock table锁住jackjhu库中的一张表
mysql> lock table t1 read;
Query OK, 0 rows affected (0.00 sec)
b) 在终端2中执行flush tables
mysql> flush tables; --无返回，被阻塞..
c) 此时终端3欲连接到jackjhu库，如果mysql连接时没有使用-A，将出现阻塞。
mysql> use jackjhu
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
--无返回，被阻塞
重新使用-A选项连接终端3执行select jackjhu库中表t1，阻塞。
mysql> select * from t1; --无返回，被阻塞..
d) 新建终端4，使用-A选项连接mysql，到jackjhu库中查询其他表 --无返回，被阻塞..
mysql> select * from t2;
+----+---------+
| id | name |
+----+---------+
| 5 | mysql |
| 6 | test |
+----+---------+
2 rows in set (0.01 sec)
退出终端，重新使用不带-A选项连接mysql，选中jackjhu。
mysql> use jackjhu
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
--无返回，被阻塞..
查看现在的线程情况，并分析阻塞的原因。
mysql> show full processlist;
+----+------+-----------+---------+------------+------+-------------------------+-----------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+---------+------------+------+-------------------------+-----------------------+
| 2 | root | localhost | jackjhu | Query | 0 | init | show full processlist |
| 3 | root | localhost | jackjhu | Query | 33 | Waiting for table flush | flush tables |
| 7 | root | localhost | jackjhu | Query | 20 | Waiting for table flush | select * from t1 |
| 12 | root | localhost | jackjhu | Field List | 10 | Waiting for table flush | |
+----+------+-----------+---------+------------+------+-------------------------+-----------------------+4 rows in set (0.00 sec) 
首先查看waiting for table ..的官方解释：
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.
分析
ID 3：终端2，由于t1被终端1锁住（lock table t1 read），flush操作中需要刷新表t1缓冲并关闭表，被阻塞，表被锁无法关闭。
ID:6：终端3，查询t1表的内容，由于查询前有flush操作，flush操作会发出表需要被重新打开的信号。终端3的查询需要重新打开t1表，显然也被阻塞，由我们上面的实验知道，打开其他没有被锁定的表是可以的，他们已经完成flush并可以被打开。
不使用-A连接mysql，被阻塞。线程状态：Field List。解释：
The thread is retrieving information for table columns.
由于表t1需要被reopen阻塞，所以这里也被阻塞。
从show full processlist这个表象上看，好像是flush tables引起的问题，其实问题的根源在于这个操作被阻塞，也就是表t1被锁住，或无法释放被关闭。
发生条件：同样ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, OPTIMIZE TABLE等操作也会出现这样的问题，这面是实验结果。
条件1：lock table t1 read
repair table, alter table(create index…),rename table,optimize table
以上操作和之后的select出现 Waiting for table metadata lock
analyze table t1操作正常，但是后面的select出现 Waiting for table metadata lock
--无field List锁
条件2：lock table t1 write
仅仅说一下和条件1中情况不同的，其他一样。
analyze table
以上操作和之后的select出现 Waiting for table metadata lock
--无field List锁
注意这里使用了lock table .. read简单的进行了模拟，实际上生产环境中大多数是由于长查询，导致flush table一直等待无法关闭该表导致。
MySQL Flush操作的bug
现象：如上文模拟的情况，如果在生产环境中发现waiting for table flush，阻塞了大量的sql。这时候为了解决问题，kill掉flush tables这个操作，这并不能解决问题， 需要reopen的标记依然会存在而没有被清除，后面的select依然没能被继续。
MySQL Bug： http://bugs.mysql.com/bug.php?id=44884
出现waiting for table.. 的解决办法
找到阻塞FLUSH TABLES, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, OPTIMIZE TABLE等操作的源头，或许是lock table操作和有表锁，或许是一个长长的查询(可以从proceelist的time列找到)，总之，我们可以很容易定位到哪张表引起的问题，再去定位sql语句，从这个方向去思考，可以比较容易的解决这样的问题。
最后看看flush tables with read lock的行为，先看看官方解释：
Closes all open tables and locks all tables for all databases with a global read lock.
关闭打开的表。
mysql> flush table with read lock;
Query OK, 0 rows affected (0.00 sec)
mysql> show global status like ‘%open%‘;
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| Com_ha_open | 0 |
| Com_show_open_tables | 0 |
| Open_files | 7 |
| Open_streams | 0 |
| Open_table_definitions | 0 | --表结构文件被关闭
| Open_tables | 0 | --表被关闭
| Opened_files | 561 |
| Opened_table_definitions | 101 |
| Opened_tables | 101 |
| Slave_open_temp_tables | 0 |
+--------------------------+-------+
10 rows in set (0.00 sec)
给mysql全局的读锁。
mysql> flush table with read lock;
Query OK, 0 rows affected (0.00 sec)
mysql> show global status like ‘%open%‘;
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| Com_ha_open | 0 |
| Com_show_open_tables | 0 |
| Open_files | 7 |
| Open_streams | 0 |
| Open_table_definitions | 0 |
| Open_tables | 0 |
| Opened_files | 561 |
| Opened_table_definitions | 101 |
| Opened_tables | 101 |
| Slave_open_temp_tables | 0 |
+--------------------------+-------+
10 rows in set (0.00 sec)
对于写入操作近些阻塞，写入操作被锁等待
mysql> insert into t3 values(3,‘uncommit‘);--无返回，等待，processlist中状态如下：
|Query | 37 | Waiting for global read lock | insert into t3 values(3,‘uncommit‘) |
如果事务在flush with read lock前已经有数据写入，但是还没有提交，此时提交的话也会被阻塞。
Query | 3 | Waiting for commit lock | commit
转载：http://bubuko.com/infodetail-254680.html