這篇文章將為大家詳細(xì)講解有關(guān)MySQL中查詢事物與DDL引發(fā)Waiting for table metadata lock的兩個階段是什么，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

創(chuàng)新互聯(lián)建站為企業(yè)級客戶提高一站式互聯(lián)網(wǎng)+設(shè)計服務(wù)，主要包括網(wǎng)站制作、成都做網(wǎng)站、app軟件開發(fā)公司、微信小程序定制開發(fā)、宣傳片制作、LOGO設(shè)計等，幫助客戶快速提升營銷能力和企業(yè)形象，創(chuàng)新互聯(lián)各部門都有經(jīng)驗豐富的經(jīng)驗，可以確保每一個作品的質(zhì)量和創(chuàng)作周期，同時每年都有很多新員工加入，為我們帶來大量新的創(chuàng)意。 

1.現(xiàn)象描述：
SESSION1：

SESSION2：


SESSION3：


備注：（這里SESSION1，SESSION2，SESSION3按先后順序執(zhí)行）
當(dāng)SESSION1未提交時，SESSION2阻塞，SESSION3阻塞
當(dāng)SESSION1提交時，SESSION2仍然阻塞，SESSION3執(zhí)行成功（這里限于篇幅，讀者可以自行實驗）


2.現(xiàn)象質(zhì)疑：
當(dāng)session1未提交時，我們看看metadata_locks,由下圖我們可以分析得出，是session1的SHARE_READ阻塞了EXCLUSIVE，同時SESSION3的SHARE_READ被EXCLUSIVE給阻塞了


當(dāng)SESSION1提交后，我們再來看metadata_locks（如下圖）：我們發(fā)現(xiàn)SESSION2被SESSION3阻塞了，且還是SESSION3的EXCLUSIVE被SESSION2的SHARE_READ阻塞了，這里我們不經(jīng)疑惑，難道是SESSION3的SHARD_READ的優(yōu)先級要高些？（但是本人查看MDL_SHARE_READ的源碼注釋，沒有發(fā)現(xiàn)MDL_SHARE_READ的優(yōu)先級要高于MDL_EXCLUSIVE）


3.現(xiàn)象分析：
帶著上一步中標(biāo)紅部分的這個疑問，我們來查看下sql執(zhí)行耗時的各個階段，具體情況如下：

mysql> show profile;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| Waiting for table metadata loc | 1.001239 |
| After create                   | 0.000047 |
| Waiting for table metadata loc | 1.002126 |
| After create                   | 0.000047 |
| Waiting for table metadata loc | 1.000864 |
| After create                   | 0.000047 |
| Waiting for table metadata loc | 1.001443 |
| After create                   | 0.000047 |
| Waiting for table metadata loc | 1.001984 |
| After create                   | 0.000046 |
| Waiting for table metadata loc | 1.003780 |
| After create                   | 0.000049 |
| Waiting for table metadata loc | 1.003622 |
| After create                   | 0.000049 |
| Waiting for table metadata loc | 1.000299 |
| After create                   | 0.000051 |
| Waiting for table metadata loc | 1.001613 |
| After create                   | 0.000048 |
| Waiting for table metadata loc | 1.000226 |
| After create                   | 0.000077 |
| Waiting for table metadata loc | 1.000196 |
| After create                   | 0.000048 |
| Waiting for table metadata loc | 1.000574 |
| After create                   | 0.000049 |
| Waiting for table metadata loc | 1.001014 |
| After create                   | 0.000046 |
| Waiting for table metadata loc | 1.000834 |
| After create                   | 0.000047 |
| Waiting for table metadata loc | 1.001708 |
| After create                   | 0.000047 |
| Waiting for table metadata loc | 0.492941 |
| After create                   | 0.000130 |
| System lock                    | 0.000028 |
| preparing for alter table      | 0.000184 |
| altering table                 | 0.000037 |
| Waiting for table metadata loc | 1.000922 |
| altering table                 | 0.000057 |
| Waiting for table metadata loc | 1.000320 |
| altering table                 | 0.000082 |
| Waiting for table metadata loc | 1.001329 |
| altering table                 | 0.000055 |
| Waiting for table metadata loc | 1.002728 |
| altering table                 | 0.000054 |
| Waiting for table metadata loc | 1.000887 |
| altering table                 | 0.000055 |
| Waiting for table metadata loc | 1.002754 |
| altering table                 | 0.000055 |
| Waiting for table metadata loc | 1.001484 |
| altering table                 | 0.000055 |
| Waiting for table metadata loc | 1.001034 |
| altering table                 | 0.000059 |
| Waiting for table metadata loc | 1.000547 |
| altering table                 | 0.000057 |
| Waiting for table metadata loc | 1.003391 |
| altering table                 | 0.000058 |
| Waiting for table metadata loc | 1.002230 |
| altering table                 | 0.000059 |
| Waiting for table metadata loc | 1.002789 |
| altering table                 | 0.000058 |
| Waiting for table metadata loc | 1.002071 |
| altering table                 | 0.000059 |
| Waiting for table metadata loc | 1.003891 |
| altering table                 | 0.000057 |
| Waiting for table metadata loc | 1.003908 |
| altering table                 | 0.000057 |
| Waiting for table metadata loc | 1.000404 |
| altering table                 | 0.000055 |
| Waiting for table metadata loc | 1.003572 |
| altering table                 | 0.000056 |
| Waiting for table metadata loc | 1.000270 |
| altering table                 | 0.000056 |
| Waiting for table metadata loc | 1.003832 |
| altering table                 | 0.000148 |
| Waiting for table metadata loc | 1.000791 |
| altering table                 | 0.000054 |
| Waiting for table metadata loc | 1.004019 |
| altering table                 | 0.000059 |
| Waiting for table metadata loc | 1.000523 |
| altering table                 | 0.000056 |
| Waiting for table metadata loc | 1.004071 |
| altering table                 | 0.000058 |
| Waiting for table metadata loc | 1.000656 |
| altering table                 | 0.000055 |
| Waiting for table metadata loc | 1.001957 |
| altering table                 | 0.000058 |
| Waiting for table metadata loc | 1.000260 |
| altering table                 | 0.000056 |
| Waiting for table metadata loc | 1.000440 |
| altering table                 | 0.000057 |
| Waiting for table metadata loc | 1.002061 |
| altering table                 | 0.000055 |
| Waiting for table metadata loc | 0.878074 |
| altering table                 | 0.000127 |
| committing alter table to stor | 0.031622 |
| end                            | 0.000078 |
| query end                      | 0.002045 |
| closing tables                 | 0.000041 |
| freeing items                  | 0.000143 |
| logging slow query             | 0.000116 |
| cleaning up                    | 0.000043 |
+--------------------------------+----------+
100 rows in set, 1 warning (0.00 sec)

從這里我們可以看出，After create和altering table 這兩個階段最耗時，同時這里兩個階段也出現(xiàn)了Waiting for table metadata lock的字眼，說明alter table add/drop index是阻塞在這兩階段（從時間上可以看出是一秒掃描一次是否能上鎖）。
altering table這個階段我們知道修改完數(shù)據(jù)之后會上MDL_EXCLUSIVE,這樣就會與MDL_SHARE_READ阻塞，那么After create又是什么階段呢？
在oracle官方bug帖上看到oracle人員的一個回復(fù)：
At certain point ALTER TABLE needs to acquire exclusive lock on table to install a new version of .FRM and to get rid of outdated  TABLE/TABLE_SHARE/handler instances in Table and Table Definition caches. At this point it will wait for existing SELECTs to stop and will block any new SELECTs.
意思是在某個點上(從源代碼可以追蹤到這是After create階段)，alter table add/drop index需要獲得排他鎖（MDL_EXCLUSIVE），目的是新建.FRM并清除舊的TABLE,TABLE_SHARE,handler的實例，這些實例在表以及表定義緩存中；這樣，這個階段需要的排它鎖（MDL_EXCLUSIZE）也會跟MDL_SHARE_READ互斥。


4.總結(jié)：
當(dāng)線上alter table add /drop index，可能阻塞在兩個階段，一個是After create，另外一個是altering table;
通常情況下：大查詢在alter table語句執(zhí)行之前（大查詢沒執(zhí)行完而alter table 開始），alter table語句會阻塞在After create階段，大查詢在alter table語句執(zhí)行之后（alter table事物沒完成，大查詢開始），alter table會阻塞在altering table階段.

關(guān)于“MySQL中查詢事物與DDL引發(fā)Waiting for table metadata lock的兩個階段是什么”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。

網(wǎng)站欄目：MySQL中查詢事物與DDL引發(fā)Waitingfortablemetadatalock的兩個階段是什么
URL分享：http://www.rwnh.cn/article10/jscigo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、微信小程序、企業(yè)網(wǎng)站制作、Google、手機網(wǎng)站建設(shè)、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)