首页 > 数据库> > Mysql的事务与锁知识(二) 之 Mysql的锁

Mysql的事务与锁知识(二) 之 Mysql的锁

2021-01-25 15:04:05 作者：互联网

1 MySQL InnoDB锁的基本类型

1.1 锁的粒度

InnoDB和MylSAM支持的锁的类型是不同的。MylSAM只支持表锁，用lock table的语法加锁。

lock tables xxx read;
lock tables xxx write;
unlock tables ;

而InnoDB同时支持表锁和行锁。当时我们内心就产生了一个疑惑，为什么支持行锁会成为InnoDB的优势？表锁和行锁的区别到底在哪？

锁定粒度：表锁 > 行锁
加锁效率：表锁 > 行锁
冲突概率：表锁 > 行锁
并发性能：表锁 < 行锁

1.2 锁的分类

表锁
- 意向锁
行锁
- 共享锁（读锁） Shared Locks
- 排它锁（写锁） Exclusive Locks
间隙锁
插入意向锁： 是一个特殊的间隙锁。间隙锁不允许插入数据，但是插入意向锁允许多个事务同时插入数据到同一个范围。比如(4,7), —个事务插入5, —个事务插入6,不会发生锁等待。
自增锁： 是一种特殊的表锁，用来防止自增字段重复，数据插入以后就会释放，不需要等到事务提交才释放。

1.3 共享锁（读锁） Shared Locks

第一个行级别的锁就是Shared Locks （共享锁），我们获取了一行数据的读锁以后，可以用来读取数据，所以它也叫做读锁，注意不要在加上了读锁以后去写数据，不然的话可能会出现死锁的情况。而且多个事务可以共享一把读锁。

共享锁的作用： 因为共享锁会阻塞其他事务的修改，所以可以用在不允许其他事务修改数据的情况。

那怎么给一行数据加上读锁呢？
我们可以用select ..... lock in share mode; 的方式手工加上一把读锁。
释放锁有两种方式，只要事务结束，锁就会自动释放，包括提交事务和结束事务。

我们来验证一下，看看共享锁是不是可以重复获取。

transaction 1	Transaction 2
begin;
SELECT * FROM user WHERE id=1 LOCK IN SHARE MODE;
	begin;
	SELECT * FROM user WHERE id=1 LOCK IN SHARE MODE; // ok

1.4 排它锁（写锁） Exclusive Locks

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

排它锁的加锁方式有两种，

第一种是自动加排他锁:我们在操作数据的时候，包括增删改，都会默认加上一个排它锁。
第二种是手工加锁，我们用FOR UPDATE给一行数据加上一个排它锁，这个无论是在代码里面还是操作数据的工具里面，都比较常用。

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

排他锁的验证：

transaction 1	Transaction 2
begin;
UPDATE user SET name =‘二营长’ WHERE id=1;
	begin;
	SELECT * FROM user WHERE id=1 LOCK IN SHARE MODE; // BLOCKED SELECT * FROM user where id=1 FOR UPDATE; // BLOCKED DELETE FROM user where id=1;// BLOCKED

1.5 意向锁

意向锁是什么呢？我们好像从来没有听过，也从来没有使用过，其实他们是由数据库自己维护的。也就是说，当我们给一行数据加上共享锁之前，数据库会自动在这张表上面加一个意向共享锁。当我们给一行数据加上排他锁之前，数据库会自动在这张表上面加一个意向排他锁。

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

意向锁跟意向锁是不冲突的，意向锁跟行锁也不冲突。那么这两个表级别的锁存在的意义是什么呢？

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

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

transaction 1	Transaction 2
begin;
SELECT * FROM user where id=1 FOR UPDATE;
	begin;
	LOCK TABLES student WRITE; // BLOCKED UNLOCK TABLES; //释放表锁的方式

锁的作用是什么？它跟Java里面的锁是一样的，是为了解决资源竞争的问题，Java 里面的资源是对象，数据库的资源就是数据表或者数据行。
所以锁是用来解决事务对数据的并发访问的问题的。
那么，锁到底锁住了什么呢？
当一个事务锁住了一行数据的时候，其他的事务不能操作这一行数据，那它到底是锁住了这一行数据，还是锁住了这一个字段，还是锁住了别的什么东西呢？

2. 行锁的原理

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

首先我们有三张表，一张没有索引的t1,一张有主键索引的t2,一张有唯一索引的 t3。
我们先假设InnoDB的行锁锁住了是一行数据或者一条记录。
我们先来看一下t1的表结构，它有两个字段,int类型的id和varchar类型的name。
里面有4条数据，1、2、3、4。

transaction 1	Transaction 2
begin;
SELECT * FROM t1 WHERE id =1 FOR UPDATE;
	select * from t1 where id=3 for update; //blocked
	INSERT INTO t1 (id, name) VALUES (5, ‘5’); //blocked

我们在两个会话里面手工开启两个事务。
在第一个事务里面，我们通过where id =1锁住第一行数据。
在第二个事务里面，我们尝试给id = 3的这一行数据加锁，能成功吗？
很遗憾，我们看到红灯亮起，这个加锁的操作被阻塞了。这就有点奇怪了，第一个事务锁住了 id = 1的这行数据，为什么我不能操作id=3的数据呢？
我们再来操作一条不存在的数据，插入id=5。它也被阻塞了。实际上这里整张表都被锁住了。所以，我们的第一个猜想被推翻了，InnoDB的行锁锁住的应该不是Record。

那为什么在没有索引或者没有用到索引的情况下，会锁住整张表？这个问题我们先留在这里。
我们继续看第二个演示。

2.2 有主键索引的表

我们看一下t2的表结构。字段是一样的，不同的地方是id上创建了一个主键索引。里面的数据是1、4、7、10。

transaction 1	Transaction 2
begin;
select * from t2 where id=1 for update;
	select * from t2 where id=1 for update; // blocked
	select * from t2 where id=4 for update; // OK

第一种情况，使用相同的id值去加锁，冲突；使用不同的id加锁，可以加锁成功。那么，既然不是锁定一行数据，有没有可能是锁住了 id的这个字段呢？
我们继续往下验证。

2.3 唯一索引（假设锁住字段）

我们看一下t3的表结构。字段还是一样的，id上创建了一个主键索引，name上创建了一个唯一索引。里面的数据是1、4、7、10。

transaction 1	Transaction 2
begin;
select * from t3 where name= ‘4’ for update;
	select * from t3 where name = ‘4’ for update; // blocked
	select * from t3 where id = 4 for update; // blocked

在第一个事务里面，我们通过name字段去锁定值是4的这行数据。
在第二个事务里面，尝试获取一样的排它锁，肯定是失败的，这个不用怀疑。
在这里我们怀疑InnoDB的行锁锁住的是字段，所以这次我换一个字段，用id=4去给这行数据加锁，能成功吗？
很遗憾，又被阻塞了，说明行锁锁住的是字段的这个推测也是错的，否则就不会出现第一个事务锁住了name,第二个字段锁住id失败的情况。

既然锁住的不是record,也不是column, InnoDB的行锁锁住的到底是什么呢？在这三个案例里面，我们要去分析一下他们的差异在哪里，也就是这三张表的结构，是什么区别导致了加锁的行为的差异？其实答案就是索引。InnoDB的行锁，就是通过锁住索引来实现的。

那么我们还有两个问题没有解决:

为什么表里面没有索引的时候，锁住一行数据会导致锁表？或者说，如果锁住的是索引，一张表没有索引怎么办？所以，一张表有没有可能没有索引？
- 如果我们定义了主键（PRIMARY KEY）,那么InnoDB会选择主键作为聚集索引。
- 如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引。
- 如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐藏的聚集索引，它会随着行记录的写入而递增。
- 所以，为什么锁表，是因为查询没有使用索引，会进行全表扫描，然后把每一个隐
  藏的聚集索引都锁住了。
为什么通过唯一索引给数据行加锁，主键索引也会被锁住？
在InnoDB中，在辅助索引里面，索引存储的是二级索引和主键的值。比如name=4,存储的是name的索引和主键id的值4。
而主键索引里面除了索引之外，还存储了完整的数据。所以我们通过辅助索引锁定一行数据的时候，它跟我们检索数据的步骤是一样的，会通过主键值找到主键索引，然后也锁定。本质上是因为锁定的是同一行数据，是相互冲突的。

在这里插入图片描述

3. 锁的算法

我们先来看一下我们测试用的表，t2表,这张表有一个主键索引，前面我们已经见过了。我们插入了4行数据，主键id分别是1、4、7、10。

因为我们用主键索引加锁，我们这里的划分标准就是主键索引的值。

在这里插入图片描述

Record 记录: 这些数据库里面存在的主键值，我们把它叫做Record，记录，那么这里我们就有4
个 Record。
Gap间隙： 根据主键，这些存在的Record隔开的数据不存在的区间，我们把它叫做Gap,间隙，它是一个左开右开的区间。
Next-key 临键锁: 最后一个，间隙（Gap）连同它左边的记录（Record）,我们把它叫做临键的区间,它是一个左开右闭的区间。

整型的主键索引，它是可以排序的，所以才有这种区间。如果我的主键索引不是整形,是字符怎么办呢? 事实上，字符也是有顺序的。
在这里插入图片描述

3.1 记录锁

第一种情况，当我们对于唯一性的索引（包括唯一索引和主键索引）使用等值查询,精准匹配到一条记录的时候，这个时候使用的就是记录锁。

例如：

select * from user where id = 4 for update;

3.2 间隙锁

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

示例：

transaction 1	Transaction 2
begin;
select * from t2 where id = 6 for update;
	INSERT INTO ‘t2’ (‘id’, ‘name’) VALUES (5, ‘5’); // BLOCKED INSERT INTO ‘t2’ (‘id’, ‘name’) VALUES (6, ‘6’); // BLOCKED select * from t2 where id =6 for update; // OK
select * from t2 where id >20 for update;
	INSERT INTO ‘t2’ (‘id’, ‘name’) VALUES (11, ‘11’); // BLOCKED

当查询记录不存在时，使用间隙锁
注意，间隙锁主要是阻塞插入inserto相同的间隙锁之间不冲突。

3.3 临键锁

第三种情况，当我们使用了范围査询，不仅仅命中了 Record记录，还包含了 Gap 间隙，在这种情况下我们使用的就是临键锁，它是MySQL里面默认的行锁算法，相当于记录锁加上间隙锁。唯一性索引，等值査询匹配到一条记录的时候，退化成记录锁。没有匹配到任何记录的时候，退化成间隙锁。

Next-key Lock = Record Lock + Gap Lock
比如我们使用>5 and <9 的条件,它包含了记录不存在的区间，也包含了一个Record 7。锁住区间(4,7] (7,10]

transaction 1	Transaction 2
begin;
select * from t2 where id >5 and id < 9 for update;
	begin;
	select * from t2 where id =4 for update; // OK INSERT INTO ‘t2’ (‘id’, ‘name’) VALUES (6, ‘6’); // BLOCKED INSERT INTO、t2’ (‘id’, ‘name’) VALUES (8, 8); // BLOCKED select * from t2 where id =10 for update; // BLOCKED

临键锁，锁住最后一个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 fbr update;—锁住(7,10], (10,+∞)

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

3.4 小结

所以，我们再看下这张表格，为什么InnoDB的RR级别能够解决幻读的问题，就是用临键锁实现的。

事务隔离级别	P1(脏读)	P2(不可重复读)	P3(幻读)
READ UNCOMMITTED (读未提交)	Possible	Possible	Possible
READ COMMITTED (读已提交)	Not Possible	Possible	Possible
REPEATABLE READ (可重复读)	Not Possible	Not Possible	对InnoDB不可能
SERIALIZABLE (串行化)	Not Possible	Not Possible	Not Possible

最后我们来总结一下四个事务隔离级别的实现:

READ UNCOMMITTED ： RU隔离级别：不加锁。
SERIALIZABLE： Serializable所有的select语句都会被隐式的转化为select… in share mode,会和 updates delete 互斥。
REPEATABLE READ：
RR隔离级别下，普通的select使用快照读(snapshot read),底层使用MVCC来实现。
加锁的select(select … in share mode / select … for update)以及更新操作 update, delete等语句使用当前读(current read) ,底层使用记录锁、或者间隙锁、临键锁。
READ COMMITTED： RC隔离级别下，普通的select都是快照读，使用MVCC实现。
加锁的select都使用记录锁，因为没有Gap Lock。
除了两种特殊情况：外键约束检査(foreign-key constraint checking)以及重复键检査(duplicate-key checking)时会使用间隙锁封锁区间。所以RC会出现幻读的问题。

4. 事务隔离级别如何选择

RU和Serializable肯定不能用。为什么有些公司要用RC,或者说网上有些文章推荐用RC?
RC和RR主要有几个区别：

RR的间隙锁会导致锁定范围的扩大。
条件列未使用到索引 RR锁表，RC锁行。
RC的"半一致性”(semi-consistent)读可以增加update操作的并发性。
在RC中，一个update语句，如果读到一行已经加锁的记录，此时InnoDB返回记录最近提交的版本，由MySQL上层判断此版本是否满足update的where条件。若满足(需要更新)，则MySQL会重新发起一次读操作，此时会读取行的最新版本(并加锁)。

实际上，如果能够正确地使用锁(避免不使用索引去加锁),只锁定需要的数据，用默认的RR级别就可以了。

标签：事务,加锁,知识,锁住,主键,索引,Mysql,id,select
来源： https://blog.csdn.net/nonage_bread/article/details/113092311