MySQL在進(jìn)行alter table等DDL操作時(shí)，有時(shí)會(huì)出現(xiàn)Waiting for table metadata lock的等待場(chǎng)景。而且，一旦alter table TableA的操作停滯在Waiting for table metadata lock的狀態(tài)，后續(xù)對(duì)TableA的任何操作（包括讀）都無(wú)法進(jìn)行，因?yàn)樗麄円矔?huì)在Opening tables的階段進(jìn)入到Waiting for table metadata lock的鎖等待隊(duì)列。如果是產(chǎn)品環(huán)境的核心表出現(xiàn)了這樣的鎖等待隊(duì)列，就會(huì)造成災(zāi)難性的后果。

造成alter table產(chǎn)生Waiting for table metadata lock的原因其實(shí)很簡(jiǎn)單，一般是以下幾個(gè)簡(jiǎn)單的場(chǎng)景：

場(chǎng)景一：長(zhǎng)事物運(yùn)行，阻塞DDL，繼而阻塞所有同表的后續(xù)操作

通過(guò)show processlist可以看到TableA上有正在進(jìn)行的操作（包括讀），此時(shí)alter table語(yǔ)句無(wú)法獲取到metadata 獨(dú)占鎖，會(huì)進(jìn)行等待。

這是最基本的一種情形，這個(gè)和mysql 5.6中的online ddl并不沖突。一般alter table的操作過(guò)程中（見下圖），在after create步驟會(huì)獲取metadata 獨(dú)占鎖，當(dāng)進(jìn)行到altering table的過(guò)程時(shí)（通常是最花時(shí)間的步驟），對(duì)該表的讀寫都可以正常進(jìn)行，這就是online ddl的表現(xiàn)，并不會(huì)像之前在整個(gè)alter table過(guò)程中阻塞寫入。（當(dāng)然，也并不是所有類型的alter操作都能online的，具體可以參見官方手冊(cè)：http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html）
處理方法： kill 掉 DDL所在的session.

場(chǎng)景二：未提交事物，阻塞DDL，繼而阻塞所有同表的后續(xù)操作

通過(guò)show processlist看不到TableA上有任何操作，但實(shí)際上存在有未提交的事務(wù)，可以在 information_schema.innodb_trx中查看到。在事務(wù)沒有完成之前，TableA上的鎖不會(huì)釋放，alter table同樣獲取不到metadata的獨(dú)占鎖。

處理方法：通過(guò) select * from information_schema.innodb_trx\G, 找到未提交事物的sid, 然后 kill 掉，讓其回滾。

場(chǎng)景三：

通過(guò)show processlist看不到TableA上有任何操作，在information_schema.innodb_trx中也沒有任何進(jìn)行中的事務(wù)。這很可能是因?yàn)樵谝粋€(gè)顯式的事務(wù)中，對(duì)TableA進(jìn)行了一個(gè)失敗的操作（比如查詢了一個(gè)不存在的字段），這時(shí)事務(wù)沒有開始，但是失敗語(yǔ)句獲取到的鎖依然有效，沒有釋放。從performance_schema.events_statements_current表中可以查到失敗的語(yǔ)句。

官方手冊(cè)上對(duì)此的說(shuō)明如下：

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.

也就是說(shuō)除了語(yǔ)法錯(cuò)誤，其他錯(cuò)誤語(yǔ)句獲取到的鎖在這個(gè)事務(wù)提交或回滾之前，仍然不會(huì)釋放掉。because the failed statement is written to the binary log and the locks protect log consistency 但是解釋這一行為的原因很難理解，因?yàn)殄e(cuò)誤的語(yǔ)句根本不會(huì)被記錄到二進(jìn)制日志。

處理方法：通過(guò)performance_schema.events_statements_current找到其sid, kill 掉該session. 也可以 kill 掉DDL所在的session.

總之，alter table的語(yǔ)句是很危險(xiǎn)的(其實(shí)他的危險(xiǎn)其實(shí)是未提交事物或者長(zhǎng)事務(wù)導(dǎo)致的)，在操作之前最好確認(rèn)對(duì)要操作的表沒有任何進(jìn)行中的操作、沒有未提交事務(wù)、也沒有顯式事務(wù)中的報(bào)錯(cuò)語(yǔ)句。如果有alter table的維護(hù)任務(wù)，在無(wú)人監(jiān)管的時(shí)候運(yùn)行，最好通過(guò)lock_wait_timeout設(shè)置好超時(shí)時(shí)間，避免長(zhǎng)時(shí)間的metedata鎖等待。