纠正互联网上关于MySQL普通字段的行锁和表锁的实验

Netty历险记

共 7548字,需浏览 16分钟

 ·

2023-07-17 16:34

0fb9477fcd789679849284b146d013ee.webp


以上图片是截取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)



f73fdd318f3b9021055cc50538cdf3be.webp

表中数据

382b1a8f14dfefc26d93c88856b35d71.webp



f73fdd318f3b9021055cc50538cdf3be.webp

数据库版本 5.7.37

121822ba16be94384d65e471d2a0b0ae.webp



f73fdd318f3b9021055cc50538cdf3be.webp

事务隔离级别RR

2c4026a34c48d1a5333734cc4a61d171.webp



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


d543086d391040146f622da80f3e6186.webp


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,再把上面的操作执行一次



f73fdd318f3b9021055cc50538cdf3be.webp

将隔离级别改成RC

60fb3505b7c2d8e9a342682310bc9d9e.webp




开启事务,执行更新操作


b68128fd48b5ed338da6af2aaed4ad47.webp



通过 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隔离级别,会将对应记录的主键上加行级锁





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




浏览 62
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报