Mysql 死锁过程及案例详解之元数据锁MetaData Lock
生活随笔
收集整理的這篇文章主要介紹了
Mysql 死锁过程及案例详解之元数据锁MetaData Lock
小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
Mysql數(shù)據(jù)鎖MetaData Lock
元數(shù)據(jù)鎖MetaData Lock
元數(shù)據(jù)鎖MetaData Locks的主要作用是在執(zhí)行查詢或者發(fā)起事務(wù)時(shí)元數(shù)據(jù)結(jié)構(gòu)受到保護(hù)，即不被修改。
MetaData Lock是表級(jí)鎖。
MetaData Lock是排他鎖，當(dāng)該鎖存在時(shí)不能有其它的連接對(duì)表的模式進(jìn)行修改。
關(guān)于元數(shù)據(jù)鎖的最大問題是空閑事務(wù)(因網(wǎng)絡(luò)斷開或者程序Bug而導(dǎo)致的COMMIT/ROLLBACK語句沒有傳給數(shù)據(jù)庫，也沒有釋放線程而導(dǎo)致線上事務(wù)鎖定等待嚴(yán)重、連接數(shù)暴漲的情況)會(huì)阻止DDL語句的執(zhí)行。
示意案例
--Step1 會(huì)話1里查看連接ID SELECT CONNECTION_ID(); /* CONNECTION_ID() 8 */ START TRANSACTION; SELECT *,SLEEP(15) FROM emp WHERE empno=7566;--Step2 會(huì)話2里查看連接ID SELECT CONNECTION_ID(); /* CONNECTION_ID() 9 */OPTIMIZE TABLE emp;--Step3 會(huì)話3里查看查看連接ID SELECT thd_id, conn_id, state, current_statement, last_statement FROM sys.session WHERE conn_id IN (8, 9)thd_id conn_id state current_statement last_statement 49 9 Waiting for table metadata lock OPTIMIZE TABLE emp 48 8 SELECT *,SLEEP(60) FROM emp WHERE empno=7566通過這個(gè)示例我們可以看到有個(gè)會(huì)話1在執(zhí)行有個(gè)持續(xù)的事務(wù)，而在第二個(gè)會(huì)話里執(zhí)行了語句 OPTIMIZE TABLE emp（OPTIMIZE TABLE語句本身不會(huì)改變表的結(jié)構(gòu)，但是會(huì)觸發(fā)metadata lock），知道會(huì)話1里的事務(wù)提交或者回滾后會(huì)話2才能正常執(zhí)行，即metalock鎖釋放。我們也可以通過系統(tǒng)表（視圖）來查看當(dāng)前metadata lock的情況。--會(huì)話3里執(zhí)行 Connection 3> SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_NAME = 'emp'mysql> SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_NAME = 'emp' \G *************************** 1. row ***************************OBJECT_TYPE: TABLEOBJECT_SCHEMA: ShenLiang2025OBJECT_NAME: empCOLUMN_NAME: NULL OBJECT_INSTANCE_BEGIN: 139887555287408LOCK_TYPE: SHARED_READLOCK_DURATION: TRANSACTIONLOCK_STATUS: GRANTEDSOURCE: sql_parse.cc:5801OWNER_THREAD_ID: 51OWNER_EVENT_ID: 80 *************************** 2. row ***************************OBJECT_TYPE: TABLEOBJECT_SCHEMA: ShenLiang2025OBJECT_NAME: empCOLUMN_NAME: NULL OBJECT_INSTANCE_BEGIN: 139887489260736LOCK_TYPE: SHARED_NO_READ_WRITELOCK_DURATION: TRANSACTIONLOCK_STATUS: PENDINGSOURCE: sql_parse.cc:5801OWNER_THREAD_ID: 52OWNER_EVENT_ID: 13 2 rows in set (0.00 sec)這里可以看到進(jìn)程ID號(hào)是51由于是一個(gè)未完成的事務(wù)，所以獲得一個(gè)共享的讀鎖。 而進(jìn)程ID是52的會(huì)話則因?yàn)閳?zhí)行了DDL語句在等待鎖釋放，即狀態(tài)是PENDING。總結(jié)
以上是生活随笔為你收集整理的Mysql 死锁过程及案例详解之元数据锁MetaData Lock的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Mysql 死锁过程及案例详解之清空缓存
- 下一篇： Mysql 死锁过程及案例详解之显式与隐