上一篇《mysql metadata lock(一)》介紹了為什么引入MDL，MDL作用以及MDL鎖導致阻塞的幾種典型場景，文章的最后還留下了一個小小的疑問。本文將更詳細的介紹MDL，主要側重介紹MDL的原理和實現。一般而言，商業數據庫系統實現鎖，一般將鎖划分為讀鎖(共享鎖)和寫鎖(排它鎖)，為了進一步提高並發性，還會加入意向共享鎖和意向排它鎖。但是偏偏mysql的MDL搞地比較復雜，但目的也是為了提高並發度。MDL包含有9種類型，詳細參考表1。主要其實也是兩大類，只是對共享鎖做了進一步細分。
一、MDL的鎖類型
| 鎖名稱 |
鎖類型 |
說明 |
適用語句 |
| MDL_INTENTION_EXCLUSIVE |
共享鎖 |
意向鎖，鎖住一個范圍 |
任何語句都會獲取MDL意向鎖， 然后再獲取更強級別的MDL鎖。 |
| MDL_SHARED |
共享鎖，表示只訪問表結構 |
|
|
| MDL_SHARED_HIGH_PRIO |
共享鎖，只訪問表結構 |
show create table 等 只訪問INFORMATION_SCHEMA的語句 |
|
| MDL_SHARED_READ |
訪問表結構並且讀表數據 |
select語句 LOCK TABLE ... READ |
|
| MDL_SHARED_WRITE |
訪問表結構並且寫表數據 |
SELECT ... FOR UPDATE DML語句 |
|
| MDL_SHARED_UPGRADABLE |
可升級鎖，訪問表結構並且讀寫表數據 |
Alter語句中間過程會使用 |
|
| MDL_SHARED_NO_WRITE |
可升級鎖，訪問表結構並且讀寫表數據，並且禁止其它事務寫。 |
Alter語句中間過程會使用 |
|
| MDL_SHARED_NO_READ_WRITE |
可升級鎖，訪問表結構並且讀寫表數據，並且禁止其它事務讀寫。 |
LOCK TABLES ... WRITE |
|
| MDL_EXCLUSIVE |
寫鎖 |
禁止其它事務讀寫。 |
CREATE/DROP/RENAME TABLE等DDL語句。 |
表1
二、MDL的兼容性矩陣(對象維度)
說明：橫向表示其它事務已經持有的鎖，縱向表示事務想加的鎖
三、幾種典型語句的加(釋放)鎖流程
1.select語句操作MDL鎖流程
1）Opening tables階段，加共享鎖
a) 加對象級別的MDL_SHARED_READ鎖
2）事務提交階段，釋放MDL鎖
a) 釋放MDL_SHARED_READ鎖
2. DML語句操作MDL鎖流程
1）Opening tables階段，加共享鎖
a) 加global類型的MDL_INTENTION_EXCLUSIVE鎖
b) 加對象級別MDL_SHARED_WRITE鎖
2）事務提交階段，釋放MDL鎖
a) 釋放MDL_INTENTION_EXCLUSIVE鎖
b) 釋放MDL_SHARED_WRITE鎖
3. alter操作MDL鎖流程
1）Opening tables階段，加共享鎖
a) 加global類型的MDL_INTENTION_EXCLUSIVE鎖
b) 加對象級別的MDL_SHARED_UPGRADABLE鎖，升級到MDL_SHARED_NO_WRITE鎖
2）操作數據，copy data，流程如下：
a) 創建臨時表tmp，重定義tmp為修改后的表結構
b) 從原表讀取數據插入到tmp表
3）將MDL_SHARED_NO_WRITE讀鎖升級到MDL_EXCLUSIVE鎖
a) 刪除原表，將tmp重命名為原表名
4）事務提交階段，釋放MDL鎖
a) 釋放MDL_INTENTION_EXCLUSIVE鎖
b) 釋放MDL_EXCLUSIVE鎖
四、典型問題分析。
一般而言，我們關注MDL鎖，大部分情況都是線上出現異常了。那么出現異常后，我們如何去判斷是MDL鎖導致的呢。監視MDL鎖主要有兩種方法，一種是通過show processlist命令，判斷是否有事務處於“Waiting for table metadata lock”狀態，另外就是通過mysql的profile，分析特定語句在每個階段的耗時時間。
拋出幾個問題：
- select 與alter是否會相互阻塞
- dml與alter是否會相互阻塞
- select與DML是否會相互阻塞
結合第三節幾種語句的上鎖流程，我們很容易得到這三個問題的答案。語句會在阻塞在具體某個環節，可以通過profile來驗證我們的答案是否正確。
第一個問題，當執行select語句時，只要select語句在獲取MDL_SHARED_READ鎖之前，alter沒有執行到rename階段，那么select獲取MDL_SHARED_READ鎖成功，后續有alter執行到rename階段，請求MDL_EXCLUSIVE鎖時，就會被阻塞。rename階段會持有MDL_EXCLUSIVE鎖，但由於這個過程時間非常短(大頭都在copy數據階段)，並且是alter的最后一個階段，所以基本感覺不到alter會阻塞select語句。由於MDL鎖在事務提交后才釋放，若線上存在大查詢，或者存在未提交的事務，則會出現ddl卡住的現象。這里要注意的是，ddl卡住后，若再有select查詢或DML進來，都會被堵住，就會出現threadrunning飆高的情況。
第二個問題，alter在opening階段會將鎖升級到MDL_SHARED_NO_WRITE，rename階段再將升級為MDL_EXCLUSIVE，由於MDL_SHARED_NO_WRITE與MDL_SHARED_WRITE互斥，所以先執行alter或先執行DML語句，都會導致語句阻塞在opening tables階段。結合第一個和第二個問題，就可以回答《mysql metadata lock(一)》的疑問了。
第三個問題，顯然，由於MDL_SHARED_WRITE與MDL_SHARED_READ兼容，所以它們不會因為MDL而導致等待的情況。具體例子和profile分析可以參考《mysql metadata lock(一)》。這里我們要考慮一個問題，LOCK TABLE ... READ上的MDL鎖是MDL_SHARED_READ，而DML操作上的是MDL_SHARED_WRITE，那么前者和后者如何互斥？其實這個MDL是無能為力的，需要通過SERVER層的table lock來解，可以簡單做一個實驗，一個會話執行LOCK TABLE test READ，另外一個會話執行update test set xxx where id=xxx，會發現update語句堵塞，通過show processlist查看，狀態為:"Waiting for table level lock"。但是如果使用LOCK TABLE test WRITE，則狀態變為"Waiting for table metadata lock"，其實此時table lock也是堵住的，只不過MDL在之前擋住了，這說明SERVER層的table lock和MDL在同時起作用。