Transfer from: http://ctripmysqldba.iteye.com/blog/1938150 (with modifications)
When performing DDL operations such as alter table, MySQL sometimes has a waiting scene for Waiting for table metadata lock. Moreover, once the operation of alter table TableA is stuck in the state of Waiting for table metadata lock, any subsequent operations (including read) on TableA cannot be performed, because they will also enter the Waiting for table metadata lock lock at the stage of Opening tables Waiting for the queue. If such a lock waiting queue appears in the core table of the production environment, it will cause disastrous consequences.
The reason for alter table to produce Waiting for table metadata lock is actually very simple, generally the following simple scenarios:
Scenario 1: Long things running, blocking DDL, and then blocking all subsequent operations of the same table
Through the show processlist, you can see that there are ongoing operations (including reading) on TableA. At this time, the alter table statement cannot obtain the metadata exclusive lock and will wait.
This is the most basic situation, and this does not conflict with the online ddl in mysql 5.6. During the operation of the alter table (see the figure below), the metadata exclusive lock is acquired in the after create step. When proceeding to the altering table (usually the most time-consuming step), reading and writing to the table can be normal To proceed, this is the performance of online ddl, and will not block writing in the entire alter table process as before. (Of course, not all types of alter operations can be online, you can refer to the official manual for details: http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html )
Solution: kill the session where the DDL is located.
Scenario 2: Uncommitted things, blocking DDL, and then blocking all subsequent operations of the same table
I can't see any operations on TableA through show processlist, but there are actually uncommitted transactions, which can be viewed in information_schema.innodb_trx . Before the transaction is completed, the lock on TableA will not be released, and the alter table cannot also obtain the exclusive lock of metadata.
Solution: Select * from information_schema.innodb_trx \ G, find the sid of the uncommitted thing, then kill it and let it roll back.
Scene three:
I can't see any operations on TableA through the show processlist, and there are no ongoing transactions in information_schema.innodb_trx. This is probably because in an explicit transaction, a failed operation was performed on TableA (for example, a non-existent field was queried). At this time, the transaction did not start, but the lock acquired by the failed statement is still valid and not released. . The failed statements can be found from the performance_schema.events_statements_current table.
The description in the official manual is as follows:
If the server acquires metadata locks for a statement that is syntactically valid but fails during execution, it does not release the locks early. Lock release is still deferred to the end of the transaction because the failed statement is written to the binary log and the locks protect log consistency.
In other words, except for syntax errors, the locks acquired by other error statements will not be released until the transaction is committed or rolled back. Because the failed statement is written to the binary log and the locks protect log consistency but it is difficult to understand the reason for this behavior, because the wrong statement will not be recorded in the binary log at all.
Processing method: Find its sid through performance_schema.events_statements_current , kill the session. You can also kill the session where the DDL is located.
In short, the statement of the alter table is very dangerous (in fact, his danger is actually caused by uncommitted things or long transactions). Before the operation, it is best to confirm that there are no ongoing operations, no uncommitted transactions, There are no error statements in explicit transactions. If there are maintenance tasks for alter table, run when no one is supervising, it is best to set a timeout by lock_wait_timeout to avoid long wait for metata lock.
