首页 > 数据库 >花了一周时间,总算把mysql的加锁搞清楚了,再也不怕间隙锁和next-key了

花了一周时间,总算把mysql的加锁搞清楚了,再也不怕间隙锁和next-key了

时间:2023-06-17 22:45:05浏览次数:65  
标签:加锁 next 索引 code user key where 主键

接触mysql都知道在mysql中有很多锁,共享锁(S)、排他锁(X)、间隙锁(gap)、next-key,当然还有意向锁、表锁等。今天不讲别的,专门来看下innodb引擎下的锁是什么样子的。

现在有这样一条sql语句,你知道是什么锁吗?

update t set name='1' where id=10;

可能会说是锁住id=10的行锁吧,没错行锁是一定的,但锁的是id=10还是其他。。。这个就犯难了。

其实不然,要判断一条sql语句使用什么锁,不是凭猜测的,而是要有依据的。从下面几个方面入手,

1、数据库隔离级别;

2、数据库索引;

3、使用到的索引;

判断一条sql使用什么锁一定不能脱开上面的3条,否则说使用了什么锁都是毫无意义的,加什么样的锁取决于要实现什么目标,如果不是这个,那不加锁岂不是更好。先来看下事务及索引。

一、事务及索引

1.1、事务

对于innodb引擎来说是支持库事务的,事务有四大特性,分别是A(原子性)、C(一致性)、I(隔离性)、D(持久性)。

在隔离性中有四大隔离级别,分别是RU(读未提交)、RC(读已提交)、RR(可重复读)、Serirable(可串行化)。四种隔离级别会影响加锁的范围,同时加锁解决了相应隔离级别下出现的问题,比如幻读、不可重复读都可以通过加锁解决。

1.2、索引

innodb使用B+树作为索引结构,索引可分为聚集索引、非聚集索引。简单点聚集索引就是索引和数据是在一起的,而非聚集索引则是索引和数据是分开的,正好分别对应主键索引、辅助索引。

在innodb引擎中主键索引是聚集索引,在索引的叶子节点中存储的是整行数据;而在辅助索引节子点存储的主键值。

如果一条sql走的是辅助索引,那么要找到这条完整的数据,则必须再遍历主键索引B+树,读取主键索引的叶子节点获得到完整的整行数据。

innodb引擎的表最终都是通过一棵主键索引的B+树来存储数据的;辅助索引存储的仅是索引列。

搞清楚了数据库的隔离级别和索引后,再来看mysql中锁的使用情况。

有这样一张t_user表,其中id是主键,自增;u_code是唯一索引;u_name、u_address是一个辅助索引。

CREATE TABLE `t_user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `u_name` varchar(100) DEFAULT NULL,
  `u_code` varchar(100) DEFAULT NULL,
  `u_age` varchar(100) DEFAULT NULL,
  `u_address` varchar(100) DEFAULT NULL,
  `interest` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `t_user_un` (`u_code`),
  KEY `index_name_address` (`u_name`,`u_address`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4;

二、RU/RC隔离级别

看下在RU(读未提交)、RC(读已提交)两种隔离级别下的加锁情况。

2.1、select

2.1.1、主键索引

2.1.1.1、主键-等值

select * from t_user where id=1 for update;

对id=1的记录加X(排它)行锁;如该行不存在不加锁;

select * from t_user where id=1 in share mode;

对id=1的记录加S(共享)行锁;如该行不存在不加锁;

2.1.1.2、主键-范围

select * from t_user where id<=5 for update

数据中存在小于等于5的主键共有5条(1、2、3、4、5)数据,以此对这5条加X(排它)行锁,其余不加锁;

select * from t_user where id<=5 in share mode;

数据中存在小于等于5的主键共有5条(1、2、3、4、5)数据,以此对这5条加S(共享)行锁,其余不加锁;

2.1.2、唯一索引

2.1.2.1、等值

select * from t_user where u_code=001 for update;

对u_code=001的索引记录加X(排它)行锁,同时在对应的主键行上也要加X(排它)行锁,如该行不存在不加锁;

select * from t_user where u_code=001  in share mode;

对u_code=001的索引记录加S(共享)行锁,同时在对应的主键行上也要加S(共享)行锁。如该行不存在不加锁;

2.1.2.2、范围

select * from t_user where u_code<=005 for update

针对上面的语句,我们猜想会走唯一索引,但其实不是的,使用explain看下

可以看到走的是全表扫描,所以这里会给所有的主键行加X锁,同时判断是否满足条件,对不满足的会立即释放X锁。要想走唯一索引可以使用下面的语句,

explain select * from t_user 
force index(t_user_un)
where u_code <='009' for update 

这时的加锁便是对满足条件的u_code索引记录加X(排它)行锁,同时对对应的主键记录加X(排它)行锁;其余不加锁;

is share mode 也是同样的道理,只不过加的是S锁,不再演示。

 所有的更新都会表现在主键的B+树索引上,为了防止其他语句对数据进行修改,对主键行加锁便是最好的选择。

2.1.3、辅助索引

存在辅助索引(u_name,u_address)。

2.1.3.1、等值

select * from t_user where u_name='test3'  for update;

对u_name='test3'的索引记录加X(排它)行锁,同时在对应的主键行上也要加X(排它)行锁,如该行不存在不加锁;

select * from t_user where u_code=001  in share mode;

对u_code=001的索引记录加S(共享)行锁,同时在对应的主键行上也要加S(共享)行锁。如该行不存在不加锁;

2.1.3.2、范围

select * from t_user where u_code<=005 for update

对满足条件的u_code索引记录加X(排它)行锁,同时对对应的主键记录加X(排它)行锁;其余不加锁;

select * from t_user where u_code<=005 in share mode;

对满足条件的u_code索引记录加S(共享)行锁,同时对对应的主键记录加S(共享)行锁;其余不加锁;

2.2、update

更新sql的加锁情况和select的加锁情况类似,区别在于更新的时候是否有索引列。

更新索引不包含索引列

看下面这个sql

update t_user set u_address='guangzhou' where id=4;

在主键行加X(排它)锁。

在看下面这样一条,

update t_user set u_address='guangzhou' where u_code='001';

该sql会命中唯一索引,索引在唯一索引记录上会加X(排它)锁,同时在唯一索引对应的主键记录行也会加X(排它锁)。

更新包含索引列

看下面这个sql

update t_user set u_code='003' where id=4;

在主键行加X(排它)锁;另外由于u_code列是唯一索引,在u_code的索引上加X(排它)锁。

在看下面这样一条,

update t_user set u_name='test' where u_code='001';

该sql会命中唯一索引,索引在唯一索引记录上会加X(排它)锁,另外,u_name列命中辅助索引,在u_name的索引记录上加X(排它)锁,最好在唯一索引对应的主键记录行也会加X(排它)锁。

2.3、delete

delete语句的加锁情况和相应的select的语句是一样的,可根据情况具体分析;

 

RU/RC两种隔离级别下给sql加的都是行锁,不涉及范围的锁定。在RR下就不一样了,因为要解决幻读和不可重复读。

三、RR隔离级别

看下在RR(可重复读)隔离级别下的加锁情况。

3.1、select

3.1.1、主键索引

3.1.1.1、等值

select * from t_user where id=10 for update;

对id=1的记录加X(排它)行锁;

如该行不存在则会在这条不存在的记录间加gap(间隙)锁。看下面的数据

会在(7,12)间加gap锁,防止其他事务执行insert操作,防止幻读。

3.1.1.2、等值-share

select * from t_user where id=1 in share mode;

对id=1的记录加S(共享)行锁;如该行不存在则会在这条不存在的记录间加gap(间隙)锁,只不过这里是s gap。

3.1.1.3、范围-大于

数据是这样的,

select * from t_user where id>=15 for update

数据中存在大于等于15的数据,对15加X(排它)锁,对20,25,30,40加next-key,也就是(15,20],(20,25],(25,30],(30,40],(40,无穷)。

如果条件是‘>15’且15存在,则不会对15加X(排它)锁,其他的和上面一样。

如果15不存在,则加锁情况是(13,15],(15,20],(20,25],(25,30],(30,40],(40,无穷)。

在范围(大于)条件下加了间隙锁(gap),目的是阻止insert插入语句,解决幻读问题。

3.1.1.4、范围-小于

select * from t_user where id<=5 for update;

数据中存在小于等于5的主键数据,会对(1,4],(4,5],(5,6]加next-key。

如果不存在id=5的数据,则会找到离5最近的,加gap锁。

3.1.2、唯一索引

3.1.2.1、等值

select * from t_user where u_code=001 for update;

对u_code=001的索引记录加X(排它)行锁,同时在对应的主键行上也要加X(排它)行锁。如该行不存在不加锁;

select * from t_user where u_code=001  in share mode;

对u_code=001的索引记录加S(共享)行锁,同时在对应的主键行上也要加S(共享)行锁。如该行不存在不加锁;

3.1.2.2、范围

select * from t_user where u_code<=005 for update

针对上面的语句,我们猜想会走唯一索引,但其实不是的,使用explain看下

可以看到走的是全表扫描,所以这里会给所有的主键行加next-key锁,也就是会锁住全部数据范围。

要想走唯一索引可以使用下面的语句,

explain select * from t_user 
force index(t_user_un)
where u_code <='009' for update 

这时的加锁便是对满足条件的u_code索引记录加next-key锁,同时对对应的主键记录加X(排它)行锁;其余不加锁;

is share mode 也是同样的道理,只不过加的是S锁,不再演示。

3.1.3、辅助索引

 

下面的sql均会命中辅助索引(u_name,u_address)。

3.1.3.1、等值-存在

select * from t_user where u_name='3'  for update;

对u_name='test3'的索引记录加next-key锁,同时在对应的主键行上也要加X(排它)行锁,加排它锁的目的是方式update/delete;在下一个记录test1上加gap锁,加gap的目的是防止insert,综上该条语句会锁定(11,test1)范围,也就是在执行insert的时候u_name不能再(11,test1)间。

主要是u_name不是唯一索引,为了防止幻读则必须在其在的范围内(11,test1)加gap,另外对u_name=3所在的主键行加X锁,防止的是对已存在的行update/delete;换句话说防止了insert这不就解决了幻读,防止了update/delete这不就解决了不可重复读。

3.1.3.2、等值-不存在

select * from t_user where u_name='4'  for update;

u_name=4不存在,会在(3,test1)间加gap锁,也就是在insert的时候,不能插入在(3,test1)间的值,比如'31'、'a'等。防止执行insert操作,其他操作均可;

3.1.3.3、范围-大于

select * from t_user where u_name>='3' for update

对满足条件的3 test1 test2 加X(排它)锁,对3 test1 test2命中的主键加X锁;同时在(11,3)、(3,test1)、(test1,test2)、(test2,无穷)加gap防止insert。这里有小伙伴会疑惑,为什么在(11,3)间有gap锁,这是因为u_name不唯一,在(11,3)间有可能插入u_name=3的数据。

3.1.3.4、范围-小于

select * from t_user where u_name<='3' for update;

对满足条件的1 11 3加X(排它)锁,对1 11 3命中的主键加X锁;同时在(无穷,1)、(1,11)、(11,3)、(3,test1)加gap防止insert。这里有小伙伴会疑惑,为什么在(3,test1)间有gap锁,这是因为u_name不唯一,在(3,test1)间有可能插入u_name=3的数据。

3.2、update

更新操作分为更新字段中是否包含了索引字段两种情况。

3.2.1、不包含索引字段

update t_user set u_address where id=2;
update t_user set u_address where u_name>='007';

分析上面的两个更新sql的加锁情况,首先看where条件,和select  ... for update的情况是一样的;其次u_address不是索引列所以不会额外加锁。

3.2.2、包含索引字段

update t_user set u_name='000' where id=9;
update t_user set u_code='test001' where u_name='000';

上面的两条更新sql,依然是先where条件,和select ... for update的情况是一样的;其次由于u_name、u_code都会命中索引,所以会在索引上加锁,u_name是辅助索引,会加gap锁;u_code是唯一索引,会对test001加X(排它)锁;

3.3、delete

3.3.1、主键

3.3.1.1、等值

delete from t_user where id=12;

主键的等值delete,会锁定主键行,id=12不管是否存在都会锁定12这个值,其他对该行的insert/update都会是X锁。

3.3.1.2、范围

delete from t_user where id<=6;

 会锁定小于等于6的整个区间,不允许insert/update/delete

3.3.2、唯一索引

3.3.2.1、等值

delete from t_user where u_code ='007'

主键的等值delete,会锁定主键行,id=12不管是否存在都会锁定12这个值,其他对该行的insert/update都会是X锁。

3.3.2.2、范围

delete from t_user where u_code <='007'

 会锁定唯一索引记录小于等于007的区间,同时锁定相应的主键行;

3.3.3、辅助索引

3.3.3.1、等值

delete from t_user where u_name='test'

这里会命中辅助索引,所以和select...for update的加锁是一样的。同时还会对相应的唯一索引、主键索引加X锁。

3.3.3.2、范围

delete from t_user where u_name<='test'

和select ...for update的加锁是一样的。

四、Serializable隔离级别

serializable隔离级别下和RR级别下是一致的,另外serializable级别下的所有select都是徐云加锁的,加的是S锁。

五、总结

本文重点分析了innodb引擎下各种sql的加锁情况,了解sql的加锁情况可以更好的帮助我们去理解sql的执行流程,理解mysql中的很多概念,看加锁情况从“隔离级别”和“索引”两方面去综合分析。

推荐阅读

花了半天时间,使用spring-boot实现动态数据源,切换自如

spring-boot集成mybatis真的很简单吗?

仅仅是调用第三方接口那么简单吗?

参考:http://mysql.taobao.org/monthly/2018/05/04/

 

标签:加锁,next,索引,code,user,key,where,主键
From: https://www.cnblogs.com/teach/p/17488428.html

相关文章

  • Flutter 使用 Key 强制重新渲染小部件
    Flutter使用Key强制重新渲染小部件文章目录Flutter使用Key强制重新渲染小部件一、Key的作用二、强制重新渲染小部件的步骤1、创建一个Key2、将Key分配给小部件3、强制重新渲染小部件三、代码案例一、Key的作用Key在Flutter中是一个抽象类,它有两个主要的子类:LocalK......
  • UNeXt:基于 MLP 的快速医学图像分割网络
    前言 本文介绍的UNeXt是约翰霍普金斯大学发布的论文。它在早期阶段使用卷积,在潜在空间阶段使用MLP。通过一个标记化的MLP块来标记和投影卷积特征,并使用MLP对表示进行建模。对输入通道进行移位,可以专注于学习局部依赖性。本文转载自DeephubImba仅用于学术分享,若侵权请联系......
  • mybatis 3.x 升级时遇到的keyProperty问题小坑
    背景:有1个项目,原来是用的mybatis3.4.6版本,其中有一些插入mapper是这样写的:IntegerinsertEntitySelectiveShard(@Param("tableSuffix")StringtableSuffix,@Param("entity")XXXEntityentity);对应的xml片段:<insertid="insertEntitySelectiveShard"par......
  • joint_learners_next用例
    【leave-joint处理前】 【leave-joint处理结果】voters=(2)&&(1)learners_next=(1)处理后voters=(2)learners=(1)【逻辑】 ......
  • [6] Fast and Practical Secret Key Extraction by Exploiting Channel Response 论文
    摘要摘要写的很清楚,几句话说明了当前密钥发展现状,即使用RSS为基础的密钥生成解决方案的生成速率有待提升,因此本文主打一个高速率;此外本文提出了CGC算法来解决现实生活中的信道互易性差的问题;此外,其能够抵御被认为对RSS技术有害的恶意攻击!但是他的Abstract我有一点不满哈,全文都是......
  • VSCode - Check Keyboard Shortcuts related to commenting
    Clickthegearicon,thenselect'KeyboardShortcuts':Search'comment': ......
  • 高德地图 报错 USERKEY_PLAT_NOMATCH
    查过文档后发现    ......
  • 2023-06-15:说一说Redis的Key和Value的数据结构组织?
    2023-06-15:说一说Redis的Key和Value的数据结构组织?答案2023-06-15:全局哈希表Redis使用哈希表作为保存键值对的数据结构,通过哈希函数将Key映射为哈希表中的一个索引位置,使得Key-Value可以在O(1)时间复杂度内被快速访问。在Redis中,哈希表是由多个哈希桶(也称为槽位/数组元素)组成......
  • @MapKey is required
    @MapKeyisrequired 这就是mybatis的annotation的一个提醒,可以直接忽略,不影响代码编译;为啥出现这种情况,因为我们很烂,sql中返回的对象不愿意定义一个 resultMap,select默认就是返回list,不指定resultMap或者resultType,默认就是组装为map对象返回;注意:一定要指定 resultType="......
  • Mongodb - org.springframework.dao.DuplicateKeyException
    首先明确场景为mongodb,此异常在进行mongodb的插入操作时抛出,插入的主键已经存在。衍生场景,使用upsert时抛出,此处的包括了$set和$setOnInsert由于upsert非原子操作,如果在多线程环境下:线程A和线程B同时对数据库未存在的记录record1进行upsert,有可能会出现两个线程都判断为应该进行......