今天一位同學問到線上曾經碰到過連續建表，導致阻塞普通的insert、update等。不過也沒有保留現場。因此有疑問為什么建表會影響DML？

?

分析

?????????首先這個現象不是在所有場景都會碰到（否則MySQL的用戶們早就跳起來了）。

一來建表這個操作本身很快，只涉及到寫表定義文件和初始化表空間。中間涉及到redo和undo的操作也很少（這里只討論InnoDB表）。因此除非碰到磁盤IO響應不了，否則多數情況下建表操作很快結束，不會“穩定復現”

二來即使由于io原因，建表過程執行時間較長，建表操作也不會阻塞一些DML操作。

?

?????????因此只能從代碼出發看沖突的case。

?

?????????假設session 1正在執行一個create table操作，且由于io原因阻塞在寫表空間文件這個步驟上。討論session2作如下操作的場景。

?

無主鍵表insert

?????????此時insert操作由于需要申請系統自增主鍵，需要對dict_sys->mutex加鎖。而這個鎖需要等session1建表操作完成后才釋放，因此出現等待。

?

有外鍵表的操作

?????????此時session2需要判斷外鍵一致性，需要對dict_sys->mutex加鎖。

?????????這里包含幾個方面：外鍵約束的child表插入數據時和parent表刪除數據時，已經這兩個表的關聯外鍵字段被修改時，均會觸發等待。

?

有同學會說我們線上這兩種情況都禁止了，是不是就不會因為這個鎖的原因導致阻塞dml？

?

新打開表時

?????????若這個insert操作需要新打開一個表時，需要根據表名從字典中取出信息，也會觸發等待。

?????????即使原來已經打開過的表，也會因為執行了flush table或者表空間淘汰而要求下次訪問需要重新打開。

?

影響的其他操作

?????????順著dict_sys->mutex我們還可以發現有以下幾個操作，若發生在session2，都會被阻塞

1)?????????????????1)?Flush tables

2)????????????????????select * from information_schema.tables;

?

??????? 2)?以上兩個因為都要訪問到表對象列表，還比較好理解

3)?????????????? ??select * from information_schema.innodb_sys_tables;

?

?????? 3)實際上可以用另外一個鎖來單獨處理sys_tables

4)??????????????????show create table another_table

????這個是因為必須判斷是否有外鍵關聯

?

?????????簡單留個問題：為什么show tables并不會被阻塞？

總結

以上是生活随笔為你收集整理的关于MySQL建表对DML的影响的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。