1, this status indicates that a large number of thread is waiting for the slow query execution is completed.
the reason:
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.
translation
Mainly because of the slow progress of the inquiry, when performed an operation similar to the flush tables. Leading to flush tables blocked, causing subsequent queries received change notification table, you need to wait to re-open the table.
Even then stop flush tables operation will not resume immediately, these large amounts of Waiting for slow query execution will be terminated before the table flush thread will wait.
2, the operation in this case easily lead
Slow query + FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, orOPTIMIZE TABLE these operations.
For example: For example, in mysqldump, it is likely to lead to such a situation when innobackupex backup.
3, solutions
Identify slow queries kill off and prevent SQL optimization triggered again.
4, prevention measures
Do not the database during peak periods FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, orOPTIMIZE TABLE these operations.
Backup, DDL statements and other business operations try to avoid the peak.
Copy Source: https://blog.csdn.net/donghaixiaolongwang/article/details/76099697