一区二区三区在线-一区二区三区亚洲视频-一区二区三区亚洲-一区二区三区午夜-一区二区三区四区在线视频-一区二区三区四区在线免费观看

服務(wù)器之家:專注于服務(wù)器技術(shù)及軟件下載分享
分類導(dǎo)航

Mysql|Sql Server|Oracle|Redis|MongoDB|PostgreSQL|Sqlite|DB2|mariadb|Access|數(shù)據(jù)庫技術(shù)|

服務(wù)器之家 - 數(shù)據(jù)庫 - Mysql - MySQL出現(xiàn)Waiting for table metadata lock的原因方法

MySQL出現(xiàn)Waiting for table metadata lock的原因方法

2020-09-23 17:13MYSQL教程網(wǎng) Mysql

在本篇內(nèi)容里小編給大家整理了MySQL出現(xiàn)Waiting for table metadata lock的原因以及解決方法對此有需要的朋友們學(xué)習(xí)下。

MySQL在進行alter table等DDL操作時,有時會出現(xiàn)Waiting for table metadata lock的等待場景。而且,一旦alter table TableA的操作停滯在Waiting for table metadata lock的狀態(tài),后續(xù)對TableA的任何操作(包括讀)都無法進行,因為他們也會在Opening tables的階段進入到Waiting for table metadata lock的鎖等待隊列。如果是產(chǎn)品環(huán)境的核心表出現(xiàn)了這樣的鎖等待隊列,就會造成災(zāi)難性的后果。

造成alter table產(chǎn)生Waiting for table metadata lock的原因其實很簡單,一般是以下幾個簡單的場景:

場景一:長事物運行,阻塞DDL,繼而阻塞所有同表的后續(xù)操作

通過show processlist可以看到TableA上有正在進行的操作(包括讀),此時alter table語句無法獲取到metadata 獨占鎖,會進行等待。

這是最基本的一種情形,這個和mysql 5.6中的online ddl并不沖突。一般alter table的操作過程中(見下圖),在after create步驟會獲取metadata 獨占鎖,當(dāng)進行到altering table的過程時(通常是最花時間的步驟),對該表的讀寫都可以正常進行,這就是online ddl的表現(xiàn),并不會像之前在整個alter table過程中阻塞寫入。(當(dāng)然,也并不是所有類型的alter操作都能online的,具體可以參見官方手冊:http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html)
處理方法: kill 掉 DDL所在的session.

場景二:未提交事物,阻塞DDL,繼而阻塞所有同表的后續(xù)操作

通過show processlist看不到TableA上有任何操作,但實際上存在有未提交的事務(wù),可以在 information_schema.innodb_trx中查看到。在事務(wù)沒有完成之前,TableA上的鎖不會釋放,alter table同樣獲取不到metadata的獨占鎖。

處理方法:通過 select * from information_schema.innodb_trx\G, 找到未提交事物的sid, 然后 kill 掉,讓其回滾。

場景三:

通過show processlist看不到TableA上有任何操作,在information_schema.innodb_trx中也沒有任何進行中的事務(wù)。這很可能是因為在一個顯式的事務(wù)中,對TableA進行了一個失敗的操作(比如查詢了一個不存在的字段),這時事務(wù)沒有開始,但是失敗語句獲取到的鎖依然有效,沒有釋放。從performance_schema.events_statements_current表中可以查到失敗的語句。

官方手冊上對此的說明如下:

If the server acquires metadata locks for a statement that is syntactically valid but fails during execution, it does not release the locks early. Lock release is still deferred to the end of the transaction because the failed statement is written to the binary log and the locks protect log consistency.

也就是說除了語法錯誤,其他錯誤語句獲取到的鎖在這個事務(wù)提交或回滾之前,仍然不會釋放掉。because the failed statement is written to the binary log and the locks protect log consistency 但是解釋這一行為的原因很難理解,因為錯誤的語句根本不會被記錄到二進制日志。

處理方法:通過performance_schema.events_statements_current找到其sid, kill 掉該session. 也可以 kill 掉DDL所在的session.

總之,alter table的語句是很危險的(其實他的危險其實是未提交事物或者長事務(wù)導(dǎo)致的),在操作之前最好確認對要操作的表沒有任何進行中的操作、沒有未提交事務(wù)、也沒有顯式事務(wù)中的報錯語句。如果有alter table的維護任務(wù),在無人監(jiān)管的時候運行,最好通過lock_wait_timeout設(shè)置好超時時間,避免長時間的metedata鎖等待。

延伸 · 閱讀

精彩推薦
主站蜘蛛池模板: 国产馆在线观看免费的 | 日噜噜 | 久久成人伊人欧洲精品AV | 国产欧美二区三区 | 亚洲sss综合天堂久久久 | 欧美老人与小伙子性生交 | 俄罗斯freeⅹ性欧美 | 国产精品福利在线观看免费不卡 | 91亚洲精品国产自在现线 | 精品午夜寂寞影院在线观看 | 特黄特黄一级高清免费大片 | 丰满岳乱妇在线观看视频国产 | 日本一区二区三区久久 | 免费观看日本人成影片 | s0e一923春菜花在线播放 | 亚洲欧美日本在线观看 | 国产成人一区二区三区影院免费 | 欧美破苞合集 magnet | 国产-第1页-草草影院 | 日本福利片国产午夜久久 | 99re思思| 免费国产一级 | 亚洲高清无码在线 视频 | 亚洲性夜 | 99久久一香蕉国产线看观看 | 亚洲+国产+图片 | 午夜亚洲| 国内精品哆啪啪 | 图片专区小说专区卡通动漫 | 乌克兰粉嫩摘花第一次 | 99re5精品视频在线观看 | 久久综合狠狠综合久久综合88 | 免费一看一级毛片人 | 狠狠色婷婷狠狠狠亚洲综合 | 久久人妻少妇嫩草AV無碼 | 成年性香蕉漫画在线观看 | 国产福利免费看 | free嫩白的12sex性自由 | 国产日韩欧美精品在线 | 办公室出轨秘书高h | 火影小南被爆羞羞网站 |