纠正互联网上关于MySQL行锁和表锁的言论

某up主视频

以上图片是截取B站某up主的视频,我们通过实验验证这句话的正确性.

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).

表中数据如下

表中数据

数据库版本 5.7.37


数据库版本

事务隔离级别

事务隔离级别RR

开始事务,执行普通字段的更新操作

非索引字段的更新操作

begin 表示开启事务
update t_order set t_no='N00A' where t_name='A'; 中的t_name字段是一个普通字段

通过 show engine innodb status 命令查询事务的锁情况,输出信息如下

------------
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;;

解读以上数据
【1】TABLE LOCK table db0.t_order trx id 518175 lock mode IX
表示在表上加了一个意向排他锁,因为事务在获取行级排他锁之前,必须先获取表级意向排他锁
【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, 业务数据是从heap no = 2开始存储
【4】分别在表的每个主键值上加了Next-Key锁

综上,相当于在 (负无穷,1] (1,2] (2,3] (3,4] (4,正无穷) 都加了行级锁,形式上等效于表锁,但是它并不是表锁,它依然是行级锁. 如果加的是一把表锁,反而开销会小很多, 我们的实验数据只有4条,就加了4个行级锁,如果表里有10万条数据,那么就会加10万个行级锁,开销是相当大的.

因此网络上,关于 普通字段检索数据的时候将使用表锁 这个观点是不正确的,而且是不严谨的. 之所以不严谨,那么因为它并没有使用表锁,它依然是行级锁,只是这个行级锁将(负无穷,正无穷)都锁住了. 之所以说它不正确,那是因为我们的实验是基于RR隔离级别而言的,如果我们把隔离级别改成RC,我们再把上面的操作执行一次


将隔离级别改成RC


隔离级别改成RC

开启事务,执行更新操作

普通字段的更新操作

通过 show engine innodb status 命令查询事务的锁情况

------------
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;;

解读以上数据
【1】TABLE LOCK table db0.t_order trx id 518177 lock mode IX
表示在表上加了一个意向排他锁,因为事务在获取行级排他锁之前,必须先获取表级意向排他锁
【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隔离级别下,它只是在对应记录的主键上加了行级锁,并没有表锁,也没有将(负无穷,正无穷)整个范围加锁.

在实际生产中,我们大多数会选择RC隔离级别.

【结论】普通字段作为WHERE条件的更新操作
1.如果是RR隔离级别,会将主键的(负无穷,正无穷)加Next-Key锁
2.如果是RC隔离级别,会将对应记录的主键上加行级锁

网络上有许多技术言论,大家听之信之,认为就是这样,应该是这样, 然而它与实际的情况还有许多距离,需要我们亲自去探秘.

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,937评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,503评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,712评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,668评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,677评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,601评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,975评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,637评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,881评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,621评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,710评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,387评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,971评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,947评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,189评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,805评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,449评论 2 342

推荐阅读更多精彩内容