某up主視頻

以上圖片是截取B站某up主的視頻登刺，我們通過實(shí)驗(yàn)驗(yàn)證這句話的正確性.

CREATE TABLE `t_order` (
  `id` int NOT NULL,
  `t_no` varchar(64) DEFAULT NULL,
  `t_name` varchar(64) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_t_no` (`t_no`)
) ENGINE=InnoDB

表中包含主鍵（id），普通索引（t_no），以及沒有索引的字段（t_name）.

表中數(shù)據(jù)如下

表中數(shù)據(jù)

數(shù)據(jù)庫版本 5.7.37

數(shù)據(jù)庫版本

事務(wù)隔離級別

事務(wù)隔離級別RR

開始事務(wù)冗茸，執(zhí)行普通字段的更新操作

非索引字段的更新操作

begin 表示開啟事務(wù)
update t_order set t_no='N00A' where t_name='A'; 中的t_name字段是一個普通字段

通過 show engine innodb status 命令查詢事務(wù)的鎖情況崖飘，輸出信息如下

------------
TRANSACTIONS
------------
Trx id counter 518176
Purge done for trx's n:o < 518175 undo n:o < 0 state: running but idle

2 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 1
MySQL thread id 3, OS thread handle 140556094682880, query id 52 localhost root
// 在表上加了一個意向排他鎖
TABLE LOCK table `db0`.`t_order` trx id 518175 lock mode IX
// 在主鍵索引上加了Next-Key鎖榴捡，具體在哪些主鍵上加了Next-Key鎖呢? 看下面
RECORD LOCKS space id 51 page no 3 n bits 72 index PRIMARY of table `db0`.`t_order` trx id 518175 lock_mode X
// 在正無窮上加了Next-Key鎖
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;
// 在id=1上加了Next-Key鎖
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000007e81f; asc       ;;
 2: len 7; hex 38000002040b10; asc 8      ;;
 3: len 4; hex 4e303041; asc N00A;;
 4: len 1; hex 41; asc A;;
// 在id=2上加了Next-Key鎖
Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000002; asc     ;;
 1: len 6; hex 00000007e814; asc       ;;
 2: len 7; hex b1000001250110; asc     %  ;;
 3: len 4; hex 4e303032; asc N002;;
 4: len 1; hex 42; asc B;;
// 在id=3上加了Next-Key鎖
Record lock, heap no 4 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000003; asc     ;;
 1: len 6; hex 00000007e819; asc       ;;
 2: len 7; hex b4000001280110; asc     (  ;;
 3: len 4; hex 4e303033; asc N003;;
 4: len 1; hex 43; asc C;;
// 在id=4上加了Next-Key鎖
Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000004; asc     ;;
 1: len 6; hex 00000007e81a; asc       ;;
 2: len 7; hex b5000001290110; asc     )  ;;
 3: len 4; hex 4e303034; asc N004;;
 4: len 1; hex 42; asc B;;

解讀以上數(shù)據(jù)
【1】TABLE LOCK table db0.t_order trx id 518175 lock mode IX
表示在表上加了一個意向排他鎖，因?yàn)槭聞?wù)在獲取行級排他鎖之前,必須先獲取表級意向排他鎖
【2】RECORD LOCKS space id 51 page no 3 n bits 72 index PRIMARY of table db0.t_order trx id 518175 lock_mode X
表示在主鍵索引上需要加Next-Key鎖
【3】Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
表示在主鍵上的正無窮上加了一把Next-Key鎖. 主鍵上的最大值存儲在heap no = 1朱浴， 主鍵上的最小值存儲在heap no = 0吊圾， 業(yè)務(wù)數(shù)據(jù)是從heap no = 2開始存儲
【4】分別在表的每個主鍵值上加了Next-Key鎖

綜上，相當(dāng)于在 (負(fù)無窮,1] (1,2] (2,3] (3,4] (4,正無窮) 都加了行級鎖赊琳，形式上等效于表鎖街夭，但是它并不是表鎖，它依然是行級鎖. 如果加的是一把表鎖躏筏，反而開銷會小很多板丽， 我們的實(shí)驗(yàn)數(shù)據(jù)只有4條，就加了4個行級鎖趁尼，如果表里有10萬條數(shù)據(jù)埃碱，那么就會加10萬個行級鎖，開銷是相當(dāng)大的.

因此網(wǎng)絡(luò)上酥泞，關(guān)于 普通字段檢索數(shù)據(jù)的時候?qū)⑹褂帽礞i 這個觀點(diǎn)是不正確的砚殿，而且是不嚴(yán)謹(jǐn)?shù)? 之所以不嚴(yán)謹(jǐn)，那么因?yàn)樗]有使用表鎖芝囤，它依然是行級鎖似炎，只是這個行級鎖將(負(fù)無窮辛萍，正無窮)都鎖住了. 之所以說它不正確，那是因?yàn)槲覀兊膶?shí)驗(yàn)是基于RR隔離級別而言的羡藐，如果我們把隔離級別改成RC贩毕，我們再把上面的操作執(zhí)行一次

將隔離級別改成RC

隔離級別改成RC

開啟事務(wù)，執(zhí)行更新操作

普通字段的更新操作

通過 show engine innodb status 命令查詢事務(wù)的鎖情況

------------
TRANSACTIONS
------------
Trx id counter 518182
Purge done for trx's n:o < 518182 undo n:o < 0 state: running but idle
2 lock struct(s), heap size 1136, 1 row lock(s), undo log entries 1
MySQL thread id 3, OS thread handle 140556094682880, query id 62 localhost root
// 在表上加了一個意向排他鎖
TABLE LOCK table `db0`.`t_order` trx id 518177 lock mode IX
// 在主鍵索引上加了行級鎖仆嗦，具體在哪些主鍵上加了行級鎖呢? 看下面
RECORD LOCKS space id 51 page no 3 n bits 72 index PRIMARY of table `db0`.`t_order` trx id 518177 lock_mode X locks rec
but not gap
// 在id=1上加了行級鎖
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000007e821; asc      !;;
 2: len 7; hex 39000001db0e66; asc 9     f;;
 3: len 4; hex 4e303041; asc N00A;;
 4: len 1; hex 41; asc A;;

解讀以上數(shù)據(jù)
【1】TABLE LOCK table db0.t_order trx id 518177 lock mode IX
表示在表上加了一個意向排他鎖辉阶，因?yàn)槭聞?wù)在獲取行級排他鎖之前,必須先獲取表級意向排他鎖
【2】RECORD LOCKS space id 51 page no 3 n bits 72 index PRIMARY of table db0.t_order trx id 518177 lock_mode X locks rec
but not gap
表示在主鍵索引上需要加行級鎖
【3】在表的id=1的主鍵上加了行級鎖

綜上，在RC隔離級別下瘩扼，它只是在對應(yīng)記錄的主鍵上加了行級鎖谆甜，并沒有表鎖，也沒有將(負(fù)無窮集绰，正無窮)整個范圍加鎖.

在實(shí)際生產(chǎn)中规辱，我們大多數(shù)會選擇RC隔離級別.

【結(jié)論】普通字段作為WHERE條件的更新操作
1.如果是RR隔離級別，會將主鍵的(負(fù)無窮倒慧，正無窮)加Next-Key鎖
2.如果是RC隔離級別按摘，會將對應(yīng)記錄的主鍵上加行級鎖

網(wǎng)絡(luò)上有許多技術(shù)言論，大家聽之信之纫谅，認(rèn)為就是這樣炫贤，應(yīng)該是這樣， 然而它與實(shí)際的情況還有許多距離付秕，需要我們親自去探秘.