您好,登錄后才能下訂單哦!
這篇文章主要介紹了MySQL中InnoDB事務鎖閱讀鎖信息狀態的示例分析,具有一定借鑒價值,感興趣的朋友可以參考下,希望大家閱讀完這篇文章之后大有收獲,下面讓小編帶著大家一起了解一下。
⒈表結構以及數據
⑴locktest2表情況如下:id為主鍵,a為唯一索引
CREATE TABLE `locktest2` (
`id` int(11) NOT NULL,
`a` int(11) NOT NULL,
`b` varchar(30) NOT NULL DEFAULT 'xddd',
PRIMARY KEY (`id`),
UNIQUE KEY `a` (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
⑵表中存在如下數據:
mysql> select * from locktest2;
+----+----+------+
| id | a | b |
+----+----+------+
| 3 | 2 | xddd |
| 9 | 20 | ddd |
| 12 | 13 | ddd |
| 19 | 7 | cccc |
| 20 | 5 | abcd |
| 21 | 4 | fff |
+----+----+------+
⒉構造所等待
session1如下:
session2如下(session2處于了等待狀態):
⒊輸出事務鎖狀態信息以及字段注解
TABLE LOCK table `test1`.`locktest2` trx id 4955 lock mode IX
TABLE LOCK:是一個表鎖
table `test1`.`locktest2`:表鎖的表是test1庫的locktest2表
trx id 4955:這個事務的事務id(被這個事務所更新的行,行上面的DB_TRX_ID字段都是4599,這個4599主要是MVCC用來做可見性判斷)
lock mode IX:IX鎖模式,這個主要是針對多粒度鎖,在有表鎖時,提前檢測沖突
RECORD LOCKS space id 40 page no 4 n bits 80 index a of table `test1`.`locktest2` trx id 4955 lock_mode X locks gap before rec insert intention waiting
RECORD LOCKS:記錄鎖
space id 40 page no 4 n bits 80:表空間編號為40,表空間頁的編號為4,用了80位來表示表示加鎖情況(bitmap,假設heap no=2的記錄被加鎖,則在bitmap的第一個元素被置為1,其他的都為0)
index a of table `test1`.`locktest2`:鎖在test1庫locktest2表的a索引上
lock_mode X locks gap before rec insert intention waiting:鎖模式為LOCK_X,鎖類型為LOCK_GAP|LOCK_INSERT_INTENTION,這個鎖處于等待狀態;組合一下這個鎖,即為LOCK_X|LOCK_GAP|LOCK_INTENTION|LOCK_WAITING(這些不懂請參考我前面的鎖與鎖模式的文章)
Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
Record lock:記錄鎖
heap no 7:這條記錄在頁的中編號為7
PHYSICAL RECORD: n_fields 2; compact format; info bits 0:物理記錄中有兩個字段,行格式為compact;記錄信息為未標記為刪除
0: len 4; hex 80000014; asc ;;
第一個字段:長度4個字節,16進制表示的字段值,為14即十進制的20
1: len 4; hex 80000009; asc ;;
第二個字段:長度4個字節,16進制表示的字段值,為9即十進制的9
注意:上面的兩個字段組成了二級索引的記錄,即(20,9),索引字段值為20,主鍵字段為9
RECORD LOCKS space id 40 page no 3 n bits 80 index PRIMARY of table `test1`.`locktest2` trx id 4954 lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000009; asc ;;//主鍵列的值為9
1: len 6; hex 000000000f6f; asc o;;//DB_TRX_ID,即4954
2: len 7; hex d200000167011e; asc g ;;//回滾指針rollback ptr
3: len 4; hex 80000014; asc ;;//a列的值
4: len 3; hex 646464; asc ddd;;//b列的值
⒋鎖等待簡單分析(這里我們主要是看鎖狀態信息,所以這個鎖等待簡單分析下)
⑴session 1通過索引a查找記錄(where a between 13 and 20),所以會在對二級索引13加上LOCK_X|LOCK_ORDINARY|LOCK_REC,表示鎖住二級索引(7,13]這個區間;對二級索引20加上LOCK_X|LOCK_ORDINARY|LOCK_REC,表示鎖住二級索引(13,20]這個區間;對二級索引頁的supremun記錄加上LOCK_X|LOCK_ORDINARY|LOCK_REC,表示鎖住(20,+無窮大)這個區間(至于這個為什么鎖住supermum這條記錄,因為這是第一條未滿足條件的記錄);注意這里還會對找到的具體主鍵記錄(其實是表數據行)也會加鎖,但這里他對鎖等待分析不影響。
⑵session insert的唯一鍵a的值為16,這個插入的范圍在(13,20]當中,而這個范圍被加上了LOCK_X|LOCK_ORDINARY|LOCK_REC鎖,與insert的LOCK_X|LOCK_GAP|LOCK_INSERT_INTENTION沖突,所以insert語句被置為了等待狀態,即LOCK_X|LOCK_GAP|LOCK_INSERT_INTENTION/LOCK_WAITTING(這里沖突不清楚請看我前面的鎖類型與鎖模式沖突矩陣的文章).
感謝你能夠認真閱讀完這篇文章,希望小編分享的“MySQL中InnoDB事務鎖閱讀鎖信息狀態的示例分析”這篇文章對大家有幫助,同時也希望大家多多支持億速云,關注億速云行業資訊頻道,更多相關知識等著你來學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。