innodb经常锁死 mysql mysql innodb锁有哪几种

转载

墨染心语 2023-07-13 11:23:15

文章标签 innodb经常锁死 mysql 数据库 mysql 加锁数据 文章分类 MySQL 数据库

MySQL InnoDB 锁的基本类型

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

行级别的锁：

共享锁
排他锁

表级别的锁：

意向共享锁
意向排他锁

2.1 共享锁

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

Transaction1	Transaction2
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 给一行数据加上一个排它锁，这个无论是在我们的代码里面还是操作数据的工具里面，都比较常用。

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

Transaction1	Transaction2
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 里面的表锁，我们可以把它理解成一个标志。就像火车上厕所有没有人使用的灯，是用来提高加锁的效率的。

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

3 行锁的原理

3.1 没有索引的表（假设锁住记录）

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

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

Transaction1	Transaction2
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 有主键索引的表

Transaction1	Transaction2
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 唯一索引（假设锁住字段）

通过唯一索引锁定

Transaction1	Transaction2
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。

Transaction1	Transaction2
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。

Transaction1	Transaction2
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 会出现幻读的问题。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。

上一篇：graphics详解 java java中的graphics如何使用

下一篇：商店java 商店门头膜结构

提问和评论都可以，用心的回复会被更多人看到评论

发布评论

相关文章

官方博客	全部文章	热门标签	班级博客
了解我们	网站地图	意见反馈

鸿蒙开发者社区	51CTO学堂
51CTO	软考资讯