众所周知,innodb是默认行锁,当然也支持表锁。如下是对于行锁的算法进行的一些实验。
成都创新互联专注于高邮网站建设服务及定制,我们拥有丰富的企业做网站经验。 热诚为您提供高邮营销型网站建设,高邮网站制作、高邮网页设计、高邮网站官网定制、小程序制作服务,打造高邮网络公司原创品牌,更为您提供高邮网站排名全网营销落地服务。
锁的算法为:我知道是行锁,但是是如何锁的,锁多少数据
假如有个索引是:[1,2,3,7]
record lock 锁的是 1,2,3,7
gap lock 锁的是 (- ,1),(2,3),(3,7),(7,+ )反正锁的就是区间,不是行
next-key lock锁的是 (- ,1],[2,3),[3,7),[ 7,+ )既锁范围也锁行
Innodb锁算法规则如下:
在可重复读隔离级别下,innodb默认使用的是next-key lock算法,当查询的索引是主键或者唯一索引的情况下,才会退化为record lock,在使用next-key lock算法时,不仅仅会锁住范围,还会给范围最后的一个键值加一个gap lock。
其中lockmode中的X锁为左边会话中的锁,因为需要显式的commit之后才会释放锁,第二个S锁,为右边的共享锁,因为主键ID为1的已经被锁住了,所以处于锁等待状态,锁的类型为record lock
使用辅助索引a=8进行操作,这个时候理论应该对主键索引加record lock 则 主键ID=8的被锁,然后辅助索引被加next-key lock 则为:
(7,8] 然后对下一个键值加gap锁,则为:(8,11)
所以目前被锁住的记录为:
1.主键为8的被锁
2.辅助索引8的被锁
3.辅助索引8到11之间的被锁,意味着你这个时候往8到11之间写数据会报错
当使用范围条件进行更新时,此时肯定是需要加X锁的,我是用的也是主键,所以按照理论应该是加的record lock ,但是却加了gap lock,因为插入值为10的阻塞了,查看information 也提示X.GAP
这个有点晕为啥主键变成了next-key lock ,不应该是record lock么?
update20200515
在知乎看到的一个解释:
即,在无论使用主键索引还是非主键索引的时候,请求共享锁或者排他锁,innodb会给范围内的记录加锁,而范围内的间隙也会被加锁,
例如一个表t 的 id为1,2,3,7,10
假如执行如下:
select * from t where id =3 for update
那么这个时候执行
insert into t(id) values(8) 会被阻塞,因为是在请求排他锁时使用了范围,所以[3,10],甚至10以后的任何数据都无法插入。
执行
select * from t where id =3 lock in share mode
insert into t(id) values(8) 会被阻塞,因为是在请求共享锁时使用了范围,所以[3,10],甚至10以后的任何数据都无法插入。
幻读是同一事务下,连续执行两次同样的sql可能导致不同的结果,第二次返回的数据可能导致以前不存在的行。
同时一般会问它和脏读的区别,脏读为读取到其他事务未提交的数据,但是幻读是读取的其他事务已经提交的数据。
reference:
当 web 日志中出现行锁超时错误后,很多开发都会找我来排查问题,这里说下问题定位的难点!
1. MySQL 本身不会主动记录行锁等待的相关信息,所以无法有效的进行事后分析。
2. 锁争用原因有多种,很难在事后判断到底是哪一类问题场景,尤其是事后无法复现问题的时候。
3. 找到问题 SQL 后,开发无法有效从代码中挖掘出完整的事务,这也和公司框架-产品-项目的架构有关,需要靠 DBA 事后采集完整的事务 SQL 才可以进行分析。
1、在mysql数据库中如何锁定一行数据,保证不被其他的操作影响。
2、从对数据的操作类型分为读锁和写锁。从对数据操作的粒度来分:表锁和行锁。
3、现在我们建立一个表来演示数据库的行锁讲解。
4、行锁基本演示如下图所示。
5、如果两个会话操作的是不同的行,就不会互相阻塞了。