Causes and solutions for Waiting for table metadata lock in mysql

Mysql causes and solutions for Waiting for table metadata lock Metadata LockingMySQL 5.5.3 and up uses metadata locking to manage access to objects (tables, triggers, and so forth ). metadata locking is used to ensure data consistency but does involve some overhead, which increases as query volume increases. metadata contention increases the more that multiple queries attempt to access the same objects. metadata locking is not a replacement for the table definition case, and its mutxes and locks differ from the LOCK_open mutex. the following discussion provides some information about how metadata locking works. to ensure transaction serializability, the server must not permit one session to perform a data definition language (DDL) statement on a table that is used in an uncompleted transaction in another session. the server achieves this by acquiring metadata locks on tables used within a transaction and deferring release of those locks until the transaction ends. A metadata lock on a table prevents changes to the table's structure. this locking approach has the implication that a table that is being used by a transaction within one session cannot be used in DDL statements by other sessions until the transaction ends. this principle applies not only to transactional tables, but also to nontransactional tables. suppose that a session begins a transaction that uses transactional table t and nontransactional table nt as follows:

START TRANSACTION;SELECT * FROM t;SELECT * FROM nt;

 

Metadata locks are held on both t and nt until the transaction ends. if another session attempts a DDL operation on either table, it blocks until metadata lock release at transaction end. for example, a second session blocks if it attempts any of these operations:

DROP TABLE t;ALTER TABLE t ...;DROP TABLE nt;ALTER TABLE nt ...;

 

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 autocommit mode, each statement is in effect a complete transaction, so metadata locks acquir Ed for the statement are held only to the end of the statement. metadata locks acquired during a PREPARE statement are released once the statement has been prepared, even if preparation occurs within a multiple-statement transaction. before MySQL 5.5.3, when a transaction acquired the equivalent of a metadata lock for a table used within a statement, it released the lock at the end of the statemen T. this approach had the disadvantage that if a DDL statement occurred for a table that was being used by another session in an active transaction, statements cocould be written to the binary log in the wrong order A non-committed transaction uses Table A, and another session modifies table, when waiting for table metadata lock is run in insert into t select * from share and alter table t add index (play_count) is executed, the alter table statement Waiting for table met Adata lock until insert... The select statement ends. Isn't it a legend that 5.6 supports online DDL? How can I still Waiting for table metadata lock? Later, we thought that online DDL should be an SQL statement that inserts, modifies, and deletes data without Waiting for table metadata lock during the alter table operation. mySQL 5.6 enhances modify other types of alter table operations TO avoid copying the TABLE. another enhancement allows SELECT queries and insert, UPDATE, and delete (DML) statements TO proceed while the table is being altered. this combination OF features IS now known AS online DDL. then let alter table wait go. Later I found another magic thing:

mysql [localhost] {msandbox} (spc) > SHOW processlist;+----+----------+-----------+------+---------+------+---------------------------------+-------------------------------------+| Id | USER     | Host      | db   | Command | TIME | State                           | Info                                |+----+----------+-----------+------+---------+------+---------------------------------+-------------------------------------+|  5 | msandbox | localhost | spc  | Query   |    1 | Waiting FOR TABLE metadata LOCK | ALTER TABLE t ADD INDEX(play_count) ||  8 | msandbox | localhost | spc  | Query   |    3 | USER sleep                      | SELECT sleep(100) FROM t            || 10 | msandbox | localhost | spc  | Query   |    0 | init                            | SHOW processlist                    |+----+----------+-----------+------+---------+------+---------------------------------+-------------------------------------+

 

Restart and try again:

mysql [localhost] {msandbox} (spc) > SHOW processlist;+----+----------+-----------+------+---------+------+---------------------------------+-------------------------------------+| Id | USER     | Host      | db   | Command | TIME | State                           | Info                                |+----+----------+-----------+------+---------+------+---------------------------------+-------------------------------------+|  1 | msandbox | localhost | spc  | Query   |  129 | USER sleep                      | SELECT sleep(100) FROM t            ||  2 | msandbox | localhost | spc  | Query   |  102 | Waiting FOR TABLE metadata LOCK | ALTER TABLE t DROP INDEX play_count ||  3 | msandbox | localhost | spc  | Query   |    0 | init                            | SHOW processlist                    |+----+----------+-----------+------+---------+------+---------------------------------+-------------------------------------+

 

The sleep time... Over 100 seconds... Conclusion: when preparing alter table tbl, check whether the SQL statements that are running and cannot be terminated within a short period of time are operating the tbl table.