首先我建議你在對MySQL表做DDL操作時：
1 執行 show processlist 查看，要操作的表（資料庫對象）是否處於鎖狀態
1 if("未鎖定")
2 {
3 執行DDL語句
4 }else
5 {
6 三思後行
7 }
作為一個程式猿，隨著開發的進行，我們要面臨需求的變更。
隨之而來的有可能就是表結構的變化–字段的增加，字段數據類型的更新。
此時此刻，我就在Alter Table面前跪瞭。
My Sql 中 Waiting for table metadata lock，主要發生在你在Alter 一個表時，在這個表上有未完成的查詢或者操作，其獨占瞭metalock狀態下，alter 操作就會等待這個鎖釋放，接下來是一段漫長的block之旅
以下是mysql 官方對於Metadata Locking概念的解釋：
MySQL 5.5.3 and up uses metadata locking to manage concurrent access to database objects and to ensure data consistency. Metadata locking applies not just to tables, but also to schemas and stored programs (procedures, functions, triggers, and scheduled events).
Metadata locking 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 cache, and its mutexes 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 explicitly or implicitly started 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;
The server holds metadata locks on both t and nt until the transaction ends. If another session attempts a DDL or write lock 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 …;
LOCK TABLE t … WRITE;
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 acquired 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 statement. 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 could be written to the binary log in the wrong order.
此時此刻，我唯一想說的就是，假如我在犯瞭這個錯誤之前就知道這個真相是多麼幸福的事。。。