MySQL InnoDB 锁的基本类型

MySQL InnoDB 锁的基本类型

https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html

行级别的锁:

  • 共享锁
  • 排他锁

表级别的锁:

  • 意向共享锁
  • 意向排他锁

2.1 共享锁

Shared Locks (共享锁),我们获取了一行数据的读锁以后,可以用来读取数据, 所以它也叫做读锁。用 select …… lock in share mode; 的方式手工加上一把读锁。 释放锁有两种方式,只要事务结束,锁就会自动事务,包括提交事务和结束事务。

Transaction1Transaction2
begin;
SELECT * FROM student WHERE id=1 LOCK IN SHARE MODE;
BEGIN;
SELECT * FROM student WHERE id=1 LOCK IN SHARE MODE; //ok

共享锁对于同一个索引加锁,互不影响;

2.2 排它锁

Exclusive Locks(排它锁),它是用来操作数据的,所以又叫做写锁。只要一个事 务获取了一行数据的排它锁,其他的事务就不能再获取这一行数据的共享锁和排它锁

增删改,都会默认加上一个排它锁。 手工加锁,用 FOR UPDATE 给一行数据加上一个排它锁,这个无论是在我们的代码 里面还是操作数据的工具里面,都比较常用。

释放锁的方式跟前面是一样的。

Transaction1Transaction2
begin;
UPDATE student SET sname = ‘猫老公555’ WHERE id=1;
BEGIN;
SELECT * FROM student WHERE id=1 LOCK IN SHARE MODE; //加共享锁阻塞 Blocking
SELECT * FROM student where id=1 FOR UPDATE; //加排它锁阻塞 Blocking
DELETE FROM student where id=1 ;//删除也阻塞Blocking

2.3 意向锁

当我们给一行数据加上共享锁之前,数据库会自动在这张表上面加一个意向共享锁。

当我们给一行数据加上排他锁之前,数据库会自动在这张表上面加一个意向排他锁。

反过来说:

如果一张表上面至少有一个意向共享锁,说明有其他的事务给其中的某些数据行加 上了共享锁。

如果一张表上面至少有一个意向排他锁,说明有其他的事务给其中的某些数据行加 上了排他锁。

第一个,我们有了表级别的锁,在 InnoDB 里面就可以支持更多粒度的锁。

第二个作用,当我们准备给一张表加上表锁的时候,必须先要去判断有没其他的事 务锁定了其中了某些行。如果有的话,肯定不能加上表锁。那么这个时候我们就要去扫 描整张表才能确定能不能成功加上一个表锁,如果数据量特别大,比如有上千万的数据 的时候,加表锁的效率是不是很低?

但是我们引入了意向锁之后就不一样了。我只要判断这张表上面有没有意向锁,如 果有,就直接返回失败。如果没有,就可以加锁成功。所以 InnoDB 里面的表锁,我们 可以把它理解成一个标志。就像火车上厕所有没有人使用的灯,是用来提高加锁的效率 的。

Transaction1Transaction2
begin;
SELECT * FROM student where id=1 FOR UPDATE;
begin;
LOCK TABLES student WRITE; //阻塞Blocking
UNLOCK TABLES;//手动释放锁

3 行锁的原理

3.1 没有索引的表(假设锁住记录)

首先我们有三张表,一张没有索引的 t1,一张有主键索引的 t2,一张有唯一索引的 t3。

我们先假设 InnoDB 的锁锁住了是一行数据或者一条记录。

Transaction1Transaction2
begin;
SELECT * FROM t1 WHERE id =1 FOR UPDATE;//在事务1中加排他锁
select * from t1 where id=3 for update;//事务2中阻塞Blocking
INSERT INTO t1 (id, name) VALUES (5, ‘5’);//插入也阻塞

现在我们在两个会话里面手工开启两个事务。

在第一个事务里面,我们通过 where id =1 锁住第一行数据。

在第二个事务里面,我们尝试给 id=3 的这一行数据加锁,这个加锁的操作被阻塞了。

我们再来操作一条不存在的数据,插入 id=5。它也被阻塞了。

实际上这里整张表都被锁住了。所以,我们的第一个猜想被推翻了,InnoDB 的锁锁 住的应该不是 Record

3.2 有主键索引的表

Transaction1Transaction2
begin;
select * from t2 where id=1 for update;//t2表给主键索引id=1记录加排他锁
select * from t2 where id=1 for update;//第二个事务中也给id=1这条记录加,加锁失败,阻塞Blocking
select * from t2 where id=4 for update;//同样在第二个事务给id=4加排他锁,成功

第一种情况,使用相同的 id 值去加锁,冲突;使用不同的 id 加锁,可以加锁成功。 那么,既然不是锁定一行数据,有没有可能是锁住了 id 的这个字段呢?

3.3 唯一索引(假设锁住字段)

通过唯一索引锁定

Transaction1Transaction2
begin;
select * from t3 where name= ‘4’ for update;
select * from t3 where name = ‘4’ for update;//阻塞
select * from t3 where id = 4 for update;//阻塞

在第一个事务里面,我们通过 name 字段去锁定值是 4 的这行数据。

在第二个事务里面,尝试获取一样的排它锁,肯定是失败的,这个不用怀疑。

在这里我们怀疑 InnoDB 锁住的是字段,所以这次我换一个字段,用 id=4 去给这行 数据加锁,又被阻塞了,说明锁住的是字段的这个推测也是错的,否则就不会出现第一 个事务锁住了 name,第二个字段锁住 id 失败的情况。 既然锁住的不是 record,也不是 column,InnoDB 里面锁住的到底是什么呢?其实 答案就是索引。InnoDB 的行锁,就是通过锁住索引记录来实现的

索引又是什么东西?为什么它可以被锁住?

还有两个问题没有解决:

1、为什么表里面没有索引的时候,锁住一行数据会导致锁表? 或者说,如果锁住的是索引,一张表没有索引怎么办? 所以,一张表有没有可能没有索引?

  • 如果我们定义了主键(PRIMARY KEY),那么 InnoDB 会选择主键作为聚集索引。

  • 如果没有显式定义主键,则 InnoDB 会选择第一个不包含有 NULL 值的唯一索 引作为主键索引。

  • 如果也没有这样的唯一索引,则 InnoDB 会选择内置 6 字节长的 ROWID 作 为隐藏的聚集索引,它会随着行记录的写入而主键递增

    所以,为什么锁表,是因为查询没有使用索引,会进行全表扫描,然后把每一个隐 藏的聚集索引都锁住了

2、为什么通过唯一索引给数据行加锁,主键索引也会被锁住?

在 InnoDB 里面,当我们使用辅助索引的时候,它是怎么检索数据的?辅助索引的 叶子节点存储的是什么内容? 在辅助索引里面,索引存储的是二级索引和主键的值。比如name=4,存储的是name 的索引和主键 id 的值 4。 而主键索引里面除了索引之外,还存储了完整的数据。所以我们通过辅助索引锁定 一行数据的时候,它跟我们检索数据的步骤是一样的,会通过主键值找到主键索引,然 后也锁定。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-g0EBwymy-1604052014580)(https://i.loli.net/2020/06/12/fVqNyuRzip9SWP1.png)]

4 锁的算法

t2 这张表有一个主键索引。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oRp9jvQJ-1604052014581)(https://i.loli.net/2020/06/12/sWvQ5hTltXR2Brd.png)]

这些数据库里面存在的主键值,我们把它叫做 Record,记录,那么这里我们就有 4 个 Record。(记录锁

根据主键,这些存在的 Record 隔开的数据不存在的区间,我们把它叫做 Gap,间 隙,它是一个左开右开的区间, (间隙锁

间隙(Gap)连同它左边的记录(Record),我们把它叫做临键的区间,它是一个 左开右闭的区间。 (临键锁

注:如果主键是字符类型的话,会根据ASCII表进行查找

4.1 记录锁

当我们对于唯一性的索引(包括唯一索引和主键索引)使用等值查询,精准匹配到 一条记录的时候,这个时候使用的就是记录锁。 比如 where id = 1 4 7 10 。

4.2 间隙锁

当我们查询的记录不存在,没有命中任何一个 record,无论是用等值查询还是范围 查询的时候,它使用的都是间隙锁。

举个例子,where id >4 and id <7,where id = 6。

Transaction1Transaction2
begin;
select * from t2 where id =6 for update;//间隙锁,锁住了(4,7)区间
INSERT INTO t2 (id, name) VALUES (5, ‘5’);//插入失败,Blocking
INSERT INTO t2 (id, name) VALUES (6, ‘6’);//插入失败,Blocking
select * from t2 where id =6 for update;//加锁成功,
select * from t2 where id >20 for update;//间隙锁,锁住了(10,+∞)
INSERT INTO t2 (id, name) VALUES (11, ‘11’);//插入失败,Blocking

注意,间隙锁主要是阻塞插入 insert。相同的间隙锁之间不冲突。

Gap Lock 只在 RR 中存在,如果要关闭间隙锁,就是把事务隔离级别设置成 RC, 并且把 innodb_locks_unsafe_for_binlog 设置为 ON。

这种情况下除了外键约束和唯一性检查会加间隙锁,其他情况都不会用间隙锁。

4.3 临键锁

当我们使用了范围查询,不仅仅命中了 Record 记录,还包含了 Gap 间隙,在这种 情况下我们使用的就是临键锁,它是 MySQL 里面默认的行锁算法,相当于记录锁加上间 隙锁

比如我们使用>5 <9, 它包含了记录不存在的区间,也包含了一个 Record 7。

Transaction1Transaction2
begin;
select * from t2 where id >5 and id < 9 for update;//加临键锁,锁区间(4,10]
select * from t2 where id =4 for update;//加锁成功,因为不在(4,10]区间
INSERT INTO t2 (id, name) VALUES (6, ‘6’);//加锁失败,Blocking
INSERT INTO t2 (id, name) VALUES (8, ‘8’);加锁失败,Blocking
select * from t2 where id =10 for update;//加锁失败,由于包括了临键值10,

临键锁,锁住最后一个 key 的下一个左开右闭的区间。

select * from t2 where id >5 and id <=7 for update; -- 锁住(4,7]和(7,10]
select * from t2 where id >8 and id <=10 for update; -- 锁住 (7,10],(10,+∞)

为什么要锁住下一个左开右闭的区间?——就是为了解决InnoDB幻读的问题。

4.4 小结:InnoDB 隔离级别的实现

事务隔离级别脏读不可重复读幻读
未提交读(Read Uncommitted)可能可能可能
读已提交(Read Committed)不可能可能可能
可重复读(Repeatable Read)不可能不可能对InnoDB不可能
串行化(Serializable)不可能不可能不可能
  • Read Uncommited RU 隔离级别:不加锁。

  • Serializable Serializable 所有的 select 语句都会 被隐式的转化为 select … in share mode,会 和 update、delete 互斥。

  • Repeatable Read RR 隔离级别下,普通的 select 使用快照读(snapshot read),底层使用 MVCC 来实 现。

    加锁的 select(select … in share mode / select … for update)以及更新操作 update, delete 等语句使用当前读(current read),底层使用记录锁、或者间隙锁、 临键锁。

  • Read Commited

    RC 隔离级别下,普通的 select 都是快照读,使用 MVCC 实现。 加锁的 select 都使用记录锁,因为没有 Gap Lock。

    除了两种特殊情况——外键约束检查(foreign-key constraint checking)以及重复 键检查(duplicate-key checking)时会使用间隙锁封锁区间。 所以 RC 会出现幻读的问题。

    RC 隔离级别下,普通的 select 都是快照读,使用 MVCC 实现。 加锁的 select 都使用记录锁,因为没有 Gap Lock。

    除了两种特殊情况——外键约束检查(foreign-key constraint checking)以及重复 键检查(duplicate-key checking)时会使用间隙锁封锁区间。 所以 RC 会出现幻读的问题。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值