今天一個朋友遇到資料庫遇到一個嚴重的故障，故障環境如下：
MYSQL 5.6.16
RR隔離級别
GITD關閉
表現如下：
use db不能進入資料庫
show table status不能查詢到表資訊
schema.processlist來看有大量的 Waiting for table metadata lock
情急之下他殺掉了一大堆線程後發現還是不能恢複，最後殺掉了一個沒有及時送出的事物才恢複正常。也僅僅留下了如下圖的一個截圖：
還是回到上圖，我們可以歸納一下語句類型如下：
<b>1、</b>CREATE TABLE A AS SELECT B
其STATE為sending data
<b>2、</b>DROP TABLE A
其STATE為Waiting for table metadata lock
<b>3、</b>SELECT * FROM A
<b>4、 </b>SHOW TABLE STATUS[like 'A']
要分析出這個案列其實不太容易因為他是MYSQL層MDL LOCK和RR模式innodb row lock的一個綜合案列，并且我們要對schema.processlist的STATE比較敏感才行。
建議先閱讀我的如下文章來學習MDL LOCK：
http://blog.itpub.net/7728585/viewspace-2143093/
本節關于MDL LOCK的驗證使用下面兩種方式：
方式1，筆者在MDL LOCK源碼加鎖函數處加日志輸出，如果要分析各種語句加MDL LOCK的類型還隻能用這種方式，因為MDL LOCK加鎖往往一閃而過，performance_schema.metadata_locks 沒有辦法觀察到。
方式2，處于堵塞情況下使用5.7版本的performance_schema.metadata_locks觀察。
在P_S中打開mdl監測方法如下：
關于sending data這個狀态其實可以代表很多含義，從我現有的對的了解，這是MYSQL上層對SELECT類型語句的這類語句在INNODB層和MYSQL層進行資料互動的時候一個統稱，是以出現它的可能包含:
确實需要通路資料量特别大，可能需要優化。
由于INNODB 層的擷取row lock需要等待，比如我們常見的SELECT FOR UPDATE。
同時我們還需要注意在RR模式下SELECT B這一部分加鎖方式和INSERT...SELECT是一緻的參考不再贅述：
http://blog.itpub.net/7728585/viewspace-2146183/
從他反應的情況因為他在最後殺掉了一個長期的未送出的事物是以他因為是情況2。并且整個CREATE TABLE A AS SELECT B語句由于B表上某些資料庫被上了鎖而不能擷取，導緻整個語句處于sending data狀态下。
這是本案例中最重要的一環，SHOW TABLE STATUS[like 'A']居然被堵塞其STATE為Waiting for table metadata lock并且注意這裡是table因為MDL LOCK類型分為很多。我在MDL介紹的那篇文章中提到了desc 一個表的時候會上MDL_SHARED_HIGH_PRIO(SH)，其實在SHOW TABLE STATUS的時候也會對本表上MDL_SHARED_HIGH_PRIO(SH)。
方式1：
<code></code>
方式2：
兩種方式都能觀察到MDL_SHARED_HIGH_PRIO(SH)的存在并且我模拟的是處于堵塞情況下的。
但是MDL_SHARED_HIGH_PRIO(SH) 是一個優先級非常高的一個MDL LOCK類型表現如下：
相容性：
阻塞隊列優先級：
其被堵塞的條件除了被MDL_EXCLUSIVE(X)堵塞沒有其他的可能。那麼這就是一個非常重要的突破口。
這一點也是我以前不知道的,也是本案列中花時間最多的地方,前文已經分析過要讓SHOW TABLE STATUS[like 'A']這種隻會上MDL_SHARED_HIGH_PRIO(SH) MDL LOCK的語句堵塞在MDL LOCK上隻有一種可能那就是A表上了MDL_EXCLUSIVE(X)。那麼我開始
懷疑這個DDL語句在語句結束之前會對A表上MDL_EXCLUSIVE(X) ，然後進行實際測試不出所料确實是這樣的如下：
這裡比較遺憾在performance_schema.metadata_locks中并沒有顯示出MDL_EXCLUSIVE(X)，而顯示為MDL_SHARED(S) 但是我們在我輸出的日志中可以看到這裡做了更新操作将MDL_SHARED(S) 更新為了MDL_EXCLUSIVE(X)。并且由前面的相容性清單來看，隻有MDL_EXCLUSIVE(X)會堵塞MDL_SHARED_HIGH_PRIO(SH)。是以我們應該能夠确認這裡确實做了更新操作，否則SHOW TABLE STATUS[like 'A'] 是不會被堵塞的。
也許大家認為SELECT不會上鎖，但是那是在innodb 層次，在MYSQL層會上MDL_SHARED_READ(SR) 如下：
可以看到确實有MDL_SHARED_READ(SR)的存在，目前處于堵塞狀态
其相容性如下：
顯然MDL_SHARED_READ(SR) 和MDL_SHARED_HIGH_PRIO(SH)是不相容的需要等待。
這一點很好分析因為A表上了X鎖而DROP TABLE A必然上MDL_EXCLUSIVE(X)鎖它當然和MDL_EXCLUSIVE(X)不相容。如下：
其中EXCLUSIVE就是我們說的MDL_EXCLUSIVE(X)它确實存在目前處于堵塞
如果使用mysql用戶端不使用-A選項(或者 no-auto-rehash)在USE DB的時候至少要做如下事情：
1、 對db下每個表上MDL (SH) lock如下（調用MDL_context::acquire_lock 這裡給出堵塞時候的資訊）
可以看到USE DB确實也因為MDL_SHARED_HIGH_PRIO(SH) 發生了堵塞。
2、對每個表加入到table cache，并且打開表(調用open_table_from_share())
那麼這種情況就和SHOW TABLE STATUS[like 'A']被堵塞的情況一模一樣了，也是由于MDL 鎖不相容造成的。
有了前面的分析那麼我們可以梳理這個故障發生的原因如下：
1、有一個在B表上長期未送出的DML
語句會在innodb層對B表某些資料加innodb row lock。
2、由步驟1引起了CREATE TABLE A AS SELECT B的堵塞
因為RR模式下SELECT B必然對B表上滿足的資料上鎖，因為步驟1已經加鎖是以觸發等待，STATE為sending data。
3、由步驟2引起了其他語句的堵塞
因為CRATE TABLE A AS SELECT B在A表建立完成之前會上MDL_EXCLUSIVE(X),這把鎖會堵塞其他全部的關于A表的語句，包括DESC/SHOW TABLE STATUS/USE DB(非-A) 這種隻上MDL_SHARED_HIGH_PRIO(SH)MDL LOCK 的語句。STATE統一為Waiting for table metadata lock。
測試環境：
5.7.14
使用腳本：
步驟如下：
mysql> select id,COMMAND,STATE, INFO,TIME from information_schema.processlist;最後我們看到的等待狀态如下：
這樣我們就完美的模拟出線上的狀态，如果我們殺掉session1中的事物，自然就全部解鎖了，讓我們再來看一下performance_schema.metadata_locks中的輸出：
我們可以看到如上的輸出，但是需要注意LOCK_TYPE: SHARED它不可能堵塞LOCK_TYPE: SHARED_HIGH_PRIO(可以參考附錄或者我以前寫的MDL LOCK分析的文章)如上文分析這裡實際上是做了更新操作更新為了MDL_EXCLUSIVE(X)。
RC模式下雖然CREATE TABLE A SELECT B中B表不會上任何INNODB ROW LOCK但是如果B表非常大那麼A表也會處于MDL_EXCLUSIVE(X)保護下，是以也會觸發USE DB\SHOW TABLE STATUS等待的情況。
如果打開GTID不能使用CREATE TABLE A SELECT B這樣的語句。
對于DML/DDL混用的系統一定要注意并發，就像本例中如果注意到高并發下的情況可以想辦法避免。
這個案列再次說明了長期不送出的事物可能引發悲劇，是以建議監控超過N秒沒結束的事務。
使用MySQL Cli用戶端連接配接時，記得加上 -A（no-auto-rehash）選項，或者用gui用戶端連接配接時，也關閉自動擷取meta data選項，避免造成MDL鎖。（葉師傅補充）
MDL LOCK TYPE
相容性矩陣
等待隊列優先級矩陣
<code></code><code><code> </code></code>
原文釋出時間為：2017-11-11
本文作者：高鵬（重慶八怪）