开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 大数据 -> MySQL的锁机制，你真的理解了吗？ -> 正文阅读

[大数据]MySQL的锁机制，你真的理解了吗？

MySQL的锁机制

MySQL的锁机制，你真的理解了吗？

我们都知道事务并发有可能导致脏写，脏读、不可重复读，幻读等问题，而这类问题归结起来可以分为以下三类（经典读写问题）：

“读-读”：两个事务都只是读取数据，并发执行，对对方不产生任何影响。
“写-写”：两个事务都需要对数据进行修改，则有可能引发脏写，脏写是任何一种隔离级别都无法忍受的问题，因此，为了解决这个问题，在事务并发的场景下，我们需要对事务访问的数据进行加锁，让访问同一数据的事务排队访问（串行）
“读-写/写-读”：一个事务读数据，另外一个事务修改数据，则可能引发脏读、不可重复读、幻读的问题。

一、何为锁？

锁是一种内存结构，在事务执行之前是不存在锁的，换句话说就是，一开始并没有锁结构和记录相关联。

在这里插入图片描述

当一个事务想要对某条记录进行操作前，需要先查看内存中是否有锁结构和该记录相关联，若没有，则在内存中生成一个锁结构与其关联（此时称为加锁成功）：

在这里插入图片描述

trx信息指的是当前加锁成功的事务信息，is_waiting为false表示不用等待，反之，则等候。

若在事务A之前，事务B已经加锁成功了，则事务A也生成一个锁结构和该记录关联，只不过is_waiting：true，事务A需等待（加锁失败）。

在这里插入图片描述

**注意：**无论加锁成功与否，事务都会在内存生成对应的锁结构和该记录关联，只是is_waiting值的区别。

二、锁的分类

在这里插入图片描述

现在先通过图整体了解一下MySQL锁，下面会细聊的，稍安勿躁。

三、共享锁和独占锁

经过上面的讲述，我们知道“读-读”是不会产生任何并发问题的，而“写-写”、“读-写，写-读”都可能会引发一系列问题，为了兼顾以上两类情况，MySQL中锁被分成了两类：

共享锁（Shared Locks）：简称S锁，在事务要读取一条记录时，需要先获取该记录的 S锁。
独占锁（Exclusive Locks ）：又称排他锁，简称X锁，在事务要改动一条记录时，需要先获
取该记录的 X锁。

例子：

事务A对记录1加了S锁，事务B想读数据也加S锁（读读共享，加锁成功），事务C想修改数据，想加X锁（读写互斥，加锁失败），此时的事务C只能等待，只有事务A、B提交并释放S锁之后，事务C才可加锁成功。
事务A对记录1加了X锁，事务B想读数据也加S锁（读写互斥，加锁失败），事务C想修改数据，想加X锁（写写互斥，加锁失败），此时的事务B、C都只能等待，只有事务A提交并释放S锁之后，他们才可能加锁成功。

故：在这里插入图片描述

1、锁定读的语句

对即将读取的记录加S锁：

SELECT ... LOCK IN SHARE MODE;

对即将读取的记录加X锁：

SELECT ... FOR UPDATE;

S锁和X锁并不能单纯地认为一个是“读锁”，一个是“写锁”；因为读取数据的时候，可根据实际需要来选择加S锁或者X锁。

加了S锁的记录允许后来事务获取S锁，但是不允许获取X锁；加了X锁的记录不允许后来事务获取S锁和X锁（只有获取锁成功事务才会继续执行，否则阻塞等待）。

2、写操作

我们平时用到的写操作无非是一下三种：

（1）DELETE

DELETE操作并不是实实际际地把某条记录删掉，而是在B+树中找到该记录的位置，修改上面delete mark标志位，对记录进行逻辑删除。

在修改delete mark标志位之前该事务需要获取该记录的X锁，当然在B+树中定位该记录的过程，也以看作是X锁的一个锁定读过程。

（2）INSERT

一般情况下，INSERT操作不需要额外加锁，它受一种隐式锁保护，保护该记录在当前事务提交前不被其他事务访问。

（3）UPDATE

UPDATE操作比DELETE操作要复杂一些，具体情况又可以细分为以下三种：

记录键值不变，待修改列的存储空间修改前后不变：

这种情况是最简单的，我们不需要太多额外的操作，只需要在B+树中找到该记录的位置，获取该记录的X锁，最后修改即可；当然在B+树中定位该记录的过程，也以看作是X锁的一个锁定读过程。
记录键值不变，待修改列的存储空间修改前后发生变化：
这种情况下，我们需要在B+树中找到该记录的位置，获取该记录的X锁，然后删除该记录（注意这一次不是修改delete mark标志位，而是真正物理上的删除，将记录移进垃圾链表）；最后再执行INSERT操作，重新插入一条记录（INNSERT操作提供隐式锁保护，保护该记录在当前事务提交前不被其他事务访问）
记录键值发生变化：

这种情况就相当于在原记录上做 DELETE 操作之后再来一次 INSERT 操作，加锁操作就
需要按照 DELETE 和 INSERT 的规则进行了。

四、多粒度锁

前面提到的都是针对某条单一记录的锁（行级锁），根据粒度的大小，MySQL中将锁又分为了表级锁和行级锁，表级锁的粒度大（粗）

和行级锁一样，表级锁也主要是S锁和X锁两种，除了粒度不同之外，它们的性质和兼容性都是一致的，即：

如果事务A给表1加了S锁：
事务B可以获取S锁，但不能获取X锁
如果事务A给表1加了X锁：
事务B既不可以获取S锁，也不可以获取X锁

例子：

图书馆6层，内若有读者，则写者不可进，但读者是可进的；内若有写者，则读者和其他写者都不可进。

一个读者进入了图书馆就想关于给整个图书馆加了S锁，后面的读者可获取S锁，而写者无法获取X锁而阻塞；

同理，一个写者进入了图书馆就想关于给整个图书馆加了X锁，后面的读者不可获取S锁，写者无法获取X锁，都阻塞。

1、意向锁

针对上述图书馆的例子，现在问题来了，有一天，一个读者来了，他怎么知道图书馆里面有没有写者呢？同理，若来的是写者，他又怎么知道里面有没有读者呢？难道是一层层去遍历查看吗？这显然不现实，毕竟遍历的效率太低了。

为了解决这个问题，InnoDB中提出了一个新的概念——意向锁。

意向共享锁（ Intention Shared Lock ）：简称 IS锁，当事务准备给某条记录加S锁的时候，需要先给表级别加一个IS锁。
意向独占锁（ Intention Exclusive Lock ）：简称 IX锁，当事务准备给某条记录加X锁的时候，需要先给表级别加一个IX锁。

有了意向锁的存在，上述图书馆的问题就可以轻松解决了：

当读者准备进入图书馆的时候，先在图书馆大门口防置“读者阅读，写者勿进”（加IS锁），这样后来的写者看到之后就会自觉止步，而后来的读者还是可以进入的。

当写者准备进入图书馆的时候，先在图书馆大门口防置“写者撰写，禁止入内”（加IS锁），这样后来的读者和写者看到之后就会自觉止步。

其实对于意向锁我们可以有以下粗略的理解：

意向锁只是一个标志性的东西，它和我们上面提到的S锁和X锁不一样，意向锁的出现只是为了避免用遍历的方式去查看某表是否存在S锁或者X锁；IS锁和IX锁兼容。

在这里插入图片描述

2、自增锁（AUTO-INC ）

我们都知道在创建表的时候可以给某列带上AUTO_INCREMENT 属性，实现其值递增，在后面执行INSERT操作的时候若是没有显式指明该列的值，系统会自动赋予它一个递增的值。

创建表：

CREATE TABLEemp(idint NOT NULL AUTO_INCREMENT,namevarchar(255) NOT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

插入数据：

INSERT INTO emp (name) VALUES ('A'), ('B');

查看数据：其中id号是系统自动添加的递增值。

在这里插入图片描述

将数据插入分为三大类：

事先确定所需插入的行数的，比如语句：INSERT...VALUES() 和 REPLACE
事先不确定所需插入的行数的，比如语句：INSERT ... SELECT ， REPLACE ... SELECT和 LOAD DATA
虽然是普通的INSERT语句，但是指定部分新行的自动递增值：
INSERT INTO emp (id,name) VALUES (1,'a'), (NULL,'b'), (5,'c'), (NULL,'d');
另外一种特殊一点的：INSERT ... ON DUPLICATE KEY UPDATE ;

讲了数据的三种插入方式之后，我们再来谈谈InnoDB中是如何保证AUTO_INCREMENT修饰的列递增赋值的：

InnoDB中有一个叫innodb_autoinc_lock_mode 的系统变量，它的取值决定着用何种方式保证AUTO_INCREMENT修饰的列递增赋值。

innodb_autoinc_lock_mode = 0 ：
这是一种“传统的锁定模式”，在这种情况下，一律采用采用AUTO-INC锁：
每次执行插入语句时，都会在表级别加AUTO-INC锁，然后为待插入记录中AUTO_INCREMENT修饰的列分配递增的值，在整个插入过程中，其他事务受当前事务的AUTO-INC锁影响而阻塞，从而保证了一个语句中分配的递增值是连续的。

这里有一点需要特别注意的是：AUTO-INC锁的作用范围只是单个插入语句，插入完成，AUTO-INC锁就释放了，并不需要等到事务提交。
innodb_autoinc_lock_mode = 1 ：
此时，若待插入记录的数量确定，则使用AUTO-INC锁的方式；若待插入记录的数量确定，则采用一个轻量级的锁：在为AUTO_INCREMENT修饰的列生成递增值的过程中产生，和AUTO-INC锁不一样的是，这个轻量级锁在生成值之后就释放了，并不需要等整个插入语句执行完。

**在 MySQL 8.0 之前，默认innodb_autoinc_lock_mode = 1 **
innodb_autoinc_lock_mode = 2：

在这种情况下，一律采用轻量级锁，自动递增值保证在所有并发执行的所有类型的insert语句中是唯一且单调递增的。但是可能会造成不同事务中的插入语句为AUTO_INCREMENT修饰的列生成的值是交叉的，在有主从复制的场景中是不安全的。

五、InnoDB中的行锁

1、记录锁/行锁（Record Locks ）

官方的类型名称为： LOCK_REC_NOT_GAP ，记录锁顾名思义就是对一条记录上锁（对一行数据上锁），其他范围不受影响。

比如下图，若对id为2的记录加记录锁，则锁住的范围就是图中蓝色的范围：

在这里插入图片描述

2、间隙锁（Gap Locks）

Gap Locks是使得MySQL在REPEATABLE READ 隔离级别下可以解决幻读问题的方案之一。在幻读情况下加锁的最尴尬的问题是幻影记录是新插入的在插入前无法加锁（事务在第一次执行读取操作时，那些幻影记录尚不存在，我们无法给这些幻影记录加上记录锁 )，而Gap Locks的出现正好可以解决这个问题：

在这里插入图片描述