面试被问到Mysql锁别慌，我帮你梳理好了！

波波的小书房 2021-04-21

265

本文目录

latch与lock？

InnoDB Lock

行锁
意向锁(表锁)
一致性非锁定读
一致性锁定读

锁带来的问题

脏读
不可重复读
丢失更新(幻读)

锁的实现

本文介绍的锁，是基于InnoDB引擎的，InnoDB提供一致性非锁定读、行级锁支持。

latch与lock？

latch与lock是两种不同的锁，下面介绍一下两者的区别：

latch：闩锁，轻量级，锁定时间短，性能高，目的是用来保证并发线程操作临界资源的正确性，通常没有死锁检测机制，分mutex(互斥量)和rwlock(读写锁)两种；
lock：与事务相关，用来锁定数据库中的对象：表、页、行，一般仅在commit和rollback后释放(不同事务隔离级别的释放时间可能不同)，有死锁检测机制；

lock与latch的比较
	lock	latch
对象	事务	线程
保护	数据库内容	内存数据结构
持续时间	整个事务过程	临界资源
模式	行锁、意向锁	读写锁、互斥量
死锁	通过waits-for graph、time out等机制进行死锁检测与处理	无死锁检测与处理机制，仅通过应用程序加锁的顺序保证无死锁的情况发生
存在于	Lock Manager的哈希表中	每个数据结构的对象中

面试中经常问到的，或者我们接触最多的，是lock而不是latch，因此下面都是说lock。

InnoDB Lock

行锁

InnoDB有两种标准的行级锁：

共享锁S Lock：允许事务读一行数据
排它锁X Lock：允许事务删除或更新一行数据

X锁与S锁的兼容性
	X	S
X	不兼容	不兼容
S	不兼容	兼容

注意：

兼容是针对同一行数据而言的；
兼容性很好理解，因为只有读读是兼容的，而读写、写写都是不兼容的；

意向锁(表锁)

事务需要先上意向锁，然后才能上行锁，意向锁的目的在于揭示下一行将被请求的锁类型，意向锁有如下两种：

意向共享锁IS Lock：事务想要获取一张表中某几行的共享锁；
意向排它锁IX Lock：事务想要获取一张表中某几行的排它锁；

由于InnoDB支持行级别的锁，因此上了表锁后并不代表整个表都锁住了，表锁与行锁的兼容性如下表。

行锁与意向锁的兼容性
	IS	IX	S	X
IS	兼容	兼容	兼容	不兼容
IX	兼容	兼容	不兼容	不兼容
S	兼容	不兼容	兼容	不兼容
X	不兼容	不兼容	不兼容	不兼容

一致性非锁定读

一致性非锁定读是指InnoDB通过多版本控制来读取数据，如果读取的数据正在执行delete或update操作（即上了X锁），这时读取操作不会等待排它锁释放，而是去读取行的一个快照。一致性非锁定读如下图所示。

快照是指该行的之前版本，通过undo段完成的，而undo用于在事务中回滚数据，因此快照数据本身没有额外开销。并且读取快照是不需要上锁的，因为没有事务要对历史数据进行修改。

非锁定读机制极大提高了数据库的并发性。

然而并不是每个事务隔离级别都采用一致性非锁定读，即使两个事务隔离级别都是一致性非锁定读，对于快照的定义也不同。

MVCC：多版本并发控制，即快照会有多个版本。

下面介绍一下读已提交和可重复读这两种事务隔离级别对于非锁定一致性读的处理：

read committed：总是读取被锁定行最新一份快照数据，因为它是读已提交，而已提交就是最新的快照数据，但由于当前事务还未结束，故不满足隔离性;
repeatable read(Mysql默认隔离级别)：总是读取事务开始时的行数据版本，所以它叫可重复读，满足隔离性;

查询和修改默认的事务隔离级别：

select @@tx_isolation;
select @@global.tx_isolation;
SET session TRANSACTION ISOLATION LEVEL read committed;
SET global TRANSACTION ISOLATION LEVEL read committed;

session表示当前会话有效，global表示全局有效，但如果Mysql重启也还是会失效，可以在Mysql参数文件中配置默认事务隔离级别。

一致性锁定读

某些情况下，需要显式进行加锁，InnoDB对于select语句支持两种锁定读：

select ... for update，X锁
select ... lock in share mode，S锁

锁带来的问题

脏读

脏数据与脏页不同：

脏页：缓冲池已经被修改的页，但是还没有刷新到磁盘，即数据库实例内存中的页与磁盘中的页是不一致的。脏页的刷新是异步的，不影响数据库的性能；
脏数据：指事务对缓冲池中行记录的修改，还没有被提交；

对于脏页的存在很正常，只要内存与磁盘保证最终一致性即可。而脏数据，如果一个事务读到了另一个事务中未提交的数据，显然违反了事务的隔离性。

不可重复读

一个事务在未提交之前，多次读取同一数据，但读到的结果却是不一样的，称为不可重复读。发生不可重复读的原因是读到了另一个事务已提交的数据。与脏读的区别是，脏读读的是未提交的数据，而不可重复读读的是已提交的数据。违反了事务的一致性。

丢失更新（幻读）

首先看如下步骤：

事务A开启事务，并修改了一行数据；
事务B开启事务，修改了同一行数据；
事务A提交；
事务B提交；

由于数据库的update操作会上X锁，并且只有在事务提交和回滚后才会释放锁，因此第二步操作是会阻塞的，就算是最低级别的隔离也会阻塞。因此两次更新操作是顺序进行的，且第二次更新是在第一次更新提交后才进行的(提交才释放锁)，因此数据库本身的排它锁机制保证了不会发生更新丢失。

但这里要说的丢失更新，是逻辑情况下的丢失更新，再看如下步骤：

事务A开启事务，读取了一行数据，假设该行数据有一个age字段，且age=10；
事务B开启了事务，读取了同一行数据，即age=10。
事务A进行修改操作，使新age=原age+10，然后提交。
事务B进行修改操作，使新age=原age+20，注意原age，事务B使用的是自己一开始读取的10，而不是事务A提交后的20，因此修改后的age=30,然后提交；

上述操作会发生丢失更新，因为如果不发生丢失更新则最终的age=40，但最终的age=30，事务B覆盖了事务A的更新。

解决丢失更新问题需要使用序列化读的方式：

将隔离级别设为序列化读；
对读取操作上排它锁，select ... for update；

锁的实现

InnoDB有三种行锁算法：

record lock：记录锁，锁定本身；
grap lock：范围锁，锁定一个范围，不包含本身；
next-key lock：锁定范围+本身，设计的目的是为了解决幻读现象；

如果当查询的索引含有唯一属性时（比如主键索引），next-key lock会进行优化，降级为record lock，提高并发性。假设表中有1、2、5三个id，select * from tb1 where id=5 for update，由于id是唯一的，因此就没必要锁定(2,5)这个范围，而只是锁定5本身就好了，那么插入4就不会阻塞。

而对于辅助索引，使用next-key lock锁定范围。假设表中有如下值：

主键索引a	辅助索引b
1	1
2	1
5	3
7	6
10	8

select * from tb1 where b=3 for update，则主键索引还是采用record lock，即只锁定5本身，而辅助索引采用next-key locking，锁定的是(1,3)和(3,6)范围。

其实这里我也不是太明白：

1和6是开区间还是闭区间？
为什么where条件是b=3，我只锁住b=3就好了，为什么要锁住范围呢？假如我插入一条新数据(a=6,b=5)，难道就会出现幻读吗？

这两个问题我回头再深入研究，不过下面是肯定的：

select * from tb1 where b>3 for update，这里采用next-key locking锁住的是(3,正无穷)，不然就会出现幻读，即我第一次select * from tb1 where b>3返回了1条数据，此时我插入(b=5)，再select * from tb1 where b>3就是两条数据了。

锁升级

将当前锁的粒度变粗。比如，数据库可以将表的1000个行级锁升级为一个页锁，防止系统使用太多的资源来维护锁，一定程度上提高了效率。

mysql 面试

文章转载自波波的小书房，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

面试被问到Mysql锁别慌，我帮你梳理好了！

评论