前言

本章节列出了mysql在增删改查的时候，分别会涉及到哪些锁类型，又是如何交互的。
这个章节也是mysql面试基础系列的最后一章，后面准备更新redis数据类型和分布式锁相关问题。如果各位看官有什么问题的话，可以留言。

锁

之前我们也有说关于多事务并发，会出现三种情况：脏读、不可重复读、幻读
对应的解决手段呢，分四个隔离级别：

• 在Read uncommitted 读未提交隔离级别下， 脏读 、 不可重复读 、 幻读 都可能发生。
• 在 Read committed 读已提交隔离级别下， 不可重复读 、 幻读 可能发生， 脏读 不可以发生。
• 在 Repeatable Read 可重复读隔离级别下， 幻读 可能发生， 脏读 和 不可重复读 不可以发生。
• 在 Serialiazble 串行化隔离级别下，上述问题都不可以发生。

那么实现这些隔离级别的手段是不太一样的。

读已提交很简单，事务提交之后才可以读取。

实现可重复读主要手段是MVCC机制，这个在之前我们也详细讲过具体的实现逻辑了

串行化这种最严谨的隔离级别，简单理解的话就是如果多个事务操作同一条数据，无论是读、写，都要一个个排队来执行，那如何实现这个排队执行呢，就要引入这个锁的概念了。

每当一个事务想要来操作这个数据的时候，就会生成一把锁

总的来说，锁这个概念就是用于公共资源的并发控制

分类

• 共享锁：share lock 一般称为S锁，或者称为读锁，给一条数据加了这个锁之后，其他事务也可以来加这个S锁来读，但是不能写。
• 独占锁：exclusive 一般称为X锁，或者称为写锁，当数据被加了这个锁之后，其他事务不可以写也不可读。
• 意向锁：IS或者IX，当事务给记录加了行锁之后，会在表级别加上对应的意向锁，告知其他事务。还有一种是行级别的意向锁。后面细说

PS：只有S锁和S锁可以相互兼容，S锁与X锁，还有X锁与X锁之间都是互斥的。

一致性读取

这种读取方式也称为快照读，是一种无锁的读取方式，主要就是在MVCC机制中运用的。不会给任何记录加锁，是通过版本来控制同一个事务中多次读取的数据保持一致。详细可以回到上面看看。

锁定读

又叫做当前读，实现方式主要是为相关的记录加上对应的锁，防止其他事务的影响。 而加的锁又有两种类型，一种可以加S锁，lock in share mode，这时候其他事务也可以来读，但是不能写。
另一种是for update，加的是X锁，这时候其他事务不能写，也不能读。如下：

select * from user where id = 1 for update; 读写锁，排他锁
select * from user where id = 1 lock in share mode; 读锁，共享

写操作

写操作的时候，又分为删除，修改，添加三种方式。

• delete删除的时候，在数据库中底层的逻辑其实是将这个数据给隐式删除，只要当前查询不出来就可以了。所以这时候加的就是一个X锁。
• update修改的时候，又分为两种情况，一种是修改原数据记录，这时候加上一个X锁就行了。另一种是可能把这个原数据id之类的涉及到存储位置变动的操作，那先定位到数据加上X锁，然后将数据和锁都删除。再插入条新数据就可以了
• insert插入操作的时候，并不会显式的加锁，会有一种叫做隐式锁的机制来处理，我们后面细说。

表锁

上面我们说的这些锁操作，默认都是加在记录上的。其实我们也可以直接给表加上S锁或者X锁。

这时候问题就来了，这里的S锁和X锁的兼容性是没变的，依旧是 只有S锁和S锁可以相互兼容，S锁与X锁，还有X锁与X锁之间都是互斥的。

• 当表中某些数据存在S锁的时候，是不能加X锁的。
• 表中某些数据存在X锁，也是不能加S锁和X锁的。

但是，加表锁的时候，难道要扒拉一遍表中所有数据，看看都有没有加锁吗？ 不可能的，这辈子都不可能的。

所以这里还有一个表级意向锁的概念，每当有事务给某个记录加了锁，就要在表上加上一个意向锁。如果表记录中有S锁，那么表上肯定就有IS表级意向锁；如果表记录中有X锁，那么表上肯定就有IX表级意向锁。

所以当我们想要再表上加锁的时候，要看我们加的锁是不是和记录中的锁互斥，互斥的话就是不能加的。

其实表的锁有些鸡肋，一般情况下是用不到的。真想使用的时候可以通过这个语句手动添加：
LOCK TABLES t READ ： InnoDB 存储引擎会对表 t 加表级别的 S锁 。
LOCK TABLES t WRITE ： InnoDB 存储引擎会对表 t 加表级别的 X锁 。

行锁

上面我们已经了解了锁的大部分概念，但是在真正的记录锁/行锁使用中，还是有其他问题要解决的。

比如现在有这样一批数据，如上图。

想要在8这条记录加上一个锁，无论是加X锁或者S锁都是可以的。加上之后防止其他事务来修改数据。

但是我们已经知道隔离级别有个幻读的问题，为了解决这个问题，mysql还有一个间隙锁的概念。就是在记录与记录之间加一个间隙锁。防止当前事务处理期间，在这些数据中插入新的记录。注意，间隙锁只会加在记录的前面。 也就是说，想要给8这个数据加间隙锁的时候，默认是加在记录3和记录8之间。这时候就有个问题了，第一条还可以，那最后一条怎么加间隙锁？ 也是有办法的。

还记得之前讲页面数据结构的时候，记录是一个链表，链表的尾部会固定的指向数据页固定的一个最大记录，这个最大记录是假的。数据页出现的时候就存在，就是用来定位记录链表的最后一条数据。那么往最后一条记录加间隙锁的时候，就可以在那条（伪）最大记录上加就可以了。

如果锁住某条记录，并且顺便把间隙锁加上的这种操作，官方称为next-key锁。

当其他事务想要在这些记录中间插入数据的时候，会先判断该位置是否有间隙锁。如果存在间隙锁的话，就获取锁失败，陷入等待状态。一直等到前面的事务释放了这个锁，会唤醒等待的事务线程来竞争锁。

action：这里的锁是如何竞争，前一个事务如何唤醒后面的事务，没有找到这方面相关资料。

隐式锁

上面提过这个概念，就是在新插入一条记录的时候，并不会主动加上锁。还记得我们在MVCC机制中介绍的时候，每条记录都有一个最后修改事务id的隐藏列吗？

如果后来的事务想要给这条新记录加锁的时候，会先查看一下这个记录的最后修改id是否还在活跃中。如果还在活跃，证明当前还未提交。就主动给当前活跃的这个事务加锁，再给自己加一个等待锁。这就是一种隐式锁的概念。

死锁

如果有这样两个事务A、B，他们分别都要执行不相关的两批数据，1、2和a。但是执行执行顺序不同。A先在1、2两条记录加了锁，B先在a记录加了锁。等双方想去获取剩余记录锁的时候，发现已经被占用了，于是都在等待对方释放锁。这就造成了死锁的问题。

InnoDB会检测这种循环等待释放的死锁问题，如果检测到两个事务因为这种问题陷入了死锁，超过一定时间，InnoDB引擎会把修改记录比较少的那个事务先给回滚了，避免一直死锁。这是一种相对来说比较优的解决方式。

这说的是引擎查询导致的死锁问题，还有一种是我们分布式数据加悲观锁处理导致的死锁问题，可以改为乐观锁+版本号的操作，这里就先不展开讲了。