[[442094]]

說到 MySQL 中的鎖，相信小伙伴們多多少少都能說出來一些，例如全局鎖、表鎖、行鎖等等。

今天我想和大伙分享一個經常容易被忽略的鎖，那就是 MDL，這個鎖如果忽略了，可能會導致大問題，一起來看下。

1. MDL 鎖介紹

MDL 全稱為 meta data lock，中文稱作元數據鎖，這是從 MySQL5.5 開始引入的鎖，MDL 是為了解決 DDL 操作和 DML 操作之間的一致性。從鎖的作用范圍上來說，MDL 算是一種表級鎖，是一個 server 層的鎖。

大家想想這樣一個場景：當我們通過 alter 語句更新一張表的時候，同時又針對這張表執行了查詢語句，假設兩者同時執行，那么將來查詢到的結果可能就并不是我們想要的結果，也就是數據一致性出了問題。

為了解決這個問題，從 MySQL5.5 開始推出了 MDL。

可能有小伙伴會說好像我從來沒寫過跟 MDL 有關的鎖呀?

其實 MDL 加鎖過程是系統自動控制，無法直接干預，也不需要直接干預，當我們對一個表做增刪改查操作的時候，會自動加 MDL 讀鎖;當我們要更新表結構的時候，加 MDL 寫鎖。加讀鎖則所有線程可正常讀表的元數據，并且讀鎖不影響表的增刪改查操作，只是不能修改表結構;而加寫鎖則只有擁有鎖的線程可以讀寫元數據，即只有擁有鎖的線程才能更新表結構，其它線程不能修改表結構也不能執行相應的增刪改查。

2. MDL 鎖演示

接下來松哥通過一個簡單的例子，來和大家演示 MDL 鎖。

首先我們開啟一個會話，開啟一個事務，執行一個更新 SQL：

大家注意，由于事務沒有提交，所以現在這個更新 SQL 還持有一個 MDL 讀鎖。

接下來我們開啟一個新的會話，執行一個 alter 語句：

大家看到，在新的會話中執行 alter，就會卡住。卡住的原因在于 DDL 操作需要獲取 MDL 寫鎖，而在 MDL 中，讀讀共享，讀寫互斥，寫寫互斥。

所以現在獲取 MDL 寫鎖就會被卡住，進而導致 alter 語句被阻塞，除非前面的 update 事務提交了，釋放了 MDL 讀鎖，那么 alter 語句就可以順利拿到寫鎖，進而完成表的更新。

這就是 MDL 鎖，不需要我們手動添加手動釋放，系統會自動添加自動釋放。

3. Online DDL

MySQL5.6 開始引入了 Online DDL，很多小伙伴可能對 Online DDL 有一些了解但是不夠全面，松哥這里也和大家說一下，加深大家對 MDL 的理解。

Online DDL 從名字上就可以看出來是可以在線執行 DDL，不和其他操作沖突，具體執行流程如下：

• DDL 操作需要首先獲取 MDL 寫鎖。
• 接下來將 MDL 寫鎖降級成 MDL 讀鎖。
• 做真正的 DDL 操作，這一步也是最耗時的，由于此時我們持有的是 MDL 讀鎖，因此并不會阻塞其他的增刪改查操作。
• 做完 DDL 操作之后，接下來將 MDL 讀鎖升級成 MDL 寫鎖。
• 釋放 MDL 鎖。

看了上面的分析大家就明白了，Online DDL 并不是讓你隨時隨地可以更新表結構，也還是有限制的，只有在第三步那里可以繼續執行增刪改查，當然即使在第三步，更新表結構也是不允許的。在我們第二小節的案例中，第一步獲取 MDL 寫鎖就被卡住了。

4. 一個隱藏的問題

和 MDL 鎖相關的還有一個隱藏問題，如果不了解這個知識點，將來可能也會犯一些錯誤。

有小伙伴看了松哥上面的例子，可能會自己做下面這個實驗：

首先在一個會話中開啟事務，然后執行 alter，如下：

注意這個事務沒有提交。

接下來執行開啟另外一個會話，執行一條更新 SQL：

發現更新 SQL 竟然成功執行了，沒有發生阻塞!!!這是怎么回事呢?

這里其實就涉及到 MySQL 事務的隱式提交：所有的 DDL 語句都會導致事務隱式提交，換句話說，當你在執行 DDL 語句前，事務就已經提交了。

這就意味著帶有 DDL 語句的事務將來沒有辦法 rollback。

假設一個有一個 SQL 事務，類似下面這樣：

begin; 
A-SQL 
alter 
B-SQL 

對于上面這個 SQL 而言，執行 alter 的時候，就會提交 A-SQL 所在的事務，執行 B-SQL 時，已經不在事務里邊了。

這就要求我們在設計 DML 數據操作的事務時，盡量不要在 DML 中包含 DDL 語句。

好啦，和小伙伴們隨便聊一聊 MDL 鎖的問題，感興趣的小伙伴可以自己動手嘗試下哦。

參考資料：

http://dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html