【MySQL高级篇笔记-锁(下) 】

悠悠 2023-10-12 15:02 16阅读 0赞

此笔记为[尚硅谷][Link 1][MySQL高级][MySQL]篇部分内容

**目录**

一、概述

二、MySQL并发事务访问相同记录

1、读-读情况

2、写-写情况

3、读-写或写-读情况

4、并发问题的解决方案

三、锁的不同角度分类

1、从数据操作的类型划分：读锁、写锁

2、从数据操作的粒度划分：表级锁、页级锁、行锁

1. 表锁（Table Lock）

2.InnoDB中的行锁

3. 页锁

3、从对待锁的态度划分:乐观锁、悲观锁

1. 悲观锁（Pessimistic Locking）

2. 乐观锁（Optimistic Locking）

3.两种锁的适用场景

4、按加锁的方式划分：显式锁、隐式锁

1. 隐式锁

2. 显式锁

5、其它锁之：全局锁

6、其它锁之：死锁

四、锁的内存结构

五、锁监控

六、附录

--------------------

事务的`隔离性`由这章讲述的`锁`来实现。

# 一、概述 #

--------------------

> `锁`是计算机协调多个进程或线程`并发访问某一资源`的机制。在程序开发中会存在多线程同步的问题，当多个线程并发访问某个数据的时候，尤其是针对一些敏感的数据（比如订单、金额等），我们就需要保证这个数据在任何时刻`最多只有一个线程`在访问，保证数据的`完整性`和`一致性`。在开发过程中加锁是为了保证数据的一致性，这个思想在数据库领域中同样很重要。
> 
> 在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。为保证数据的一致性，需要对`并发操作进行控制`，因此产生了`锁`。同时`锁机制`也为实现MySQL的各个隔离级别提供了保证。`锁冲突`也是影响数据库`并发访问性能`的一个重要因素。所以锁对数据库而言显得尤其重要，也更加复杂

# 二、MySQL并发事务访问相同记录 #

--------------------

并发事务访问相同记录的情况大致可以划分为3种：

## 1、读-读情况 ##

`读-读`情况，即并发事务相继`读取相同的记录`。读取操作本身不会对记录有任何影响，并不会引起什么问题，所以允许这种情况的发生。

## 2、写-写情况 ##

![e6d12ae29df34d85b3d69782f68ca0b1.png][]

![8ea5d993210343bf956f4716e355791c.png][]

![240aa856aaec43e4945145ca039498f3.png][]

![065a779a228e4d40b789a01f2592d152.png][]

> 小结几种说法：
> 
>  *  不加锁
>     
>     意思就是不需要在内存中生成对应的`锁结构`，可以直接执行操作。
>  *  获取锁成功，或者加锁成功
>     
>     意思就是在内存中生成了对应的`锁结构`，而且锁结构的`is_waiting`属性为`false`，也就是事务 可以继续执行操作。
>  *  获取锁失败，或者加锁失败，或者没有获取到锁
>     
>     意思就是在内存中生成了对应的锁结构，不过锁结构的`is_waiting`属性为`true`，也就是事务 需要等待，不可以继续执行操作。

## 3、读-写或写-读情况 ##

> `读-写`或`写-读`，即一个事务进行读取操作，另一个进行改动操作。这种情况下可能发生`脏读`、`不可重复读`、`幻读`的问题。
> 
> 各个数据库厂商对`SQL标准的`支持都可能不一样。比如MySQL在`REPEATABLE READ`隔离级别上就已经解决了幻读问题

## 4、并发问题的解决方案 ##

![ec6b59a650f8432e82dbae918852ab59.png][]

> 小结对比发现：
> 
>  *  采用`MVCC`方式的话，`读-写`操作彼此并不冲突，`性能更高`。
>  *  采用`加锁`方式的话，`读-写`操作彼此需要`排队执行`，影响性能。
> 
> 一般情况下我们当然愿意采用`MVCC`来解决`读-写`操作并发执行的问题，但是业务在某些特殊情况下，要求必须采用`加锁`的方式执行。下面就讲解下MySQL中不同类别的锁

# 三、锁的不同角度分类 #

--------------------

锁的分类图，如下：

![2741eb862eac4e07be4d3e686bfd099c.png][]

## 1、从数据操作的类型划分：读锁、写锁 ##

>  *  读锁 ：也称为 共享锁 、英文用 S 表示。针对同一份数据，多个事务的读操作可以同时进行而不会互相影响，相互不阻塞的。
>  *  写锁 ：也称为 排他锁 、英文用 X 表示。当前写操作没有完成前，它会阻断其他写锁和读锁。这样就能确保在给定的时间里，只有一个事务能执行写入，并防止其他用户读取正在写入的同一资源。

**需要注意的是对于 InnoDB 引擎来说，读锁和写锁可以加在表上，也可以加在行上。**

![0134ae0327874d7c94b1d1979e3ac5c0.png][]

## 2、从数据操作的粒度划分：表级锁、页级锁、行锁 ##

### 1. 表锁（Table Lock） ###

**① 表级别的S锁、X锁**

![30fb745117524928891ed768cd51542c.png][]

**② 意向锁 （intention lock）**

![17aa56a132e54a30beebd25e71965f64.png][]

![89e7487b35564c35a8abeb32c5ad0e29.png][]

**③ 自增锁（AUTO-INC锁）**

![686368e874114d02a088a4b9630cb3fd.png][]

![7e8f4b9b09c44449a4d0e4d9f54265d2.png][]

![c2af7a8cdeb645998c8c363d76b4b39f.png][]

**④ 元数据锁（MDL锁）**

![d1113effdb644d34b97676c5afd714bb.png][]

### 2.InnoDB中的行锁 ###

**① 记录锁（Record Locks）**

![87149d2d94d542c7bd72cecf99bfa37b.png][]

![1846dcf2f7d447b197de179f8c7e596d.png][]

**② 间隙锁（Gap Locks）**

![548ba3e8e0834783aded613dbd5e1157.png][]

**③ 临键锁（Next-Key Locks）**

![80745624ac2d4f7c859141deb93c2faf.png][]

**④ 插入意向锁（Insert Intention Locks）**

![a091522a7e394a29905137f2d90b23f7.png][]

### 3. 页锁 ###

![39806482cd7c4870853b66e5c9d3d06e.png][]

## 3、从对待锁的态度划分:乐观锁、悲观锁 ##

> 从对待锁的态度来看锁的话，可以将锁分成乐观锁和悲观锁，从名字中也可以看出这两种锁是两种看待数据并发的思维方式 。需要注意的是，乐观锁和悲观锁并不是锁，而是锁的设计思想 。

### 1. 悲观锁（Pessimistic Locking） ###

>  *  悲观锁是一种思想，顾名思义，就是很悲观，对数据被其他事务的修改持保守态度，会通过数据库自身的锁机制来实现，从而保证数据操作的排它性。
>  *  悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 阻塞 直到它拿到锁（**共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）**。比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当其他线程想要访问数据时，都需要阻塞挂起。Java中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现。

### 2. 乐观锁（Optimistic Locking） ###

> 乐观锁认为对同一数据的并发操作不会总发生，属于小概率事件，不用每次都对数据上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，也就是 **不采用数据库自身的锁机制，而是通过程序来实现**。在程序上，我们可以采用`版本号机制`或者`CAS机制`实现。 **乐观锁适用于多读的应用类型，这样可以提高吞吐量**。在Java中java.util.concurrent.atomic包下的原子变量类就是使用了乐观锁的一种实现方式：CAS实现的。

> **1.乐观锁的版本号机制**
> 
> 在表中设计一个`版本字段 version`，第一次读的时候，会获取 version 字段的取值。然后对数据进行更新或删除操作时，会执行`UPDATE ... SET version=version+1 WHERE version=version`。此时如果已经有事务对这条数据进行了更改，修改就不会成功。
> 
> **2. 乐观锁的时间戳机制**
> 
> 时间戳和版本号机制一样，也是在更新提交的时候，将当前数据的时间戳和更新之前取得的时间戳进行 比较，如果两者一致则更新成功，否则就是版本冲突。
> 
> 你能看到乐观锁就是程序员自己控制数据并发操作的权限，基本是通过给数据行增加一个戳（版本号或 者时间戳），从而证明当前拿到的数据是否最新。

### 3.两种锁的适用场景 ###

> 从这两种锁的设计思想中，我们总结一下乐观锁和悲观锁的适用场景：
> 
> 1.  `乐观锁`适合`读操作多`的场景，相对来说写的操作比较少。它的优点在于程序实现，不存在死锁问题，不过适用场景也会相对乐观，因为它阻止不了除了程序以外的数据库操作。
> 2.  `悲观锁`适合`写操作多`的场景，因为写的操作具有`排它性`。采用悲观锁的方式，可以在数据库层面阻止其他事务对该数据的操作权限，防止`读 - 写`和`写 - 写`的冲突

## 4、按加锁的方式划分：显式锁、隐式锁 ##

### 1. 隐式锁 ###

![55a8e94e40254018b3c1f11e0e3829b2.png][]

> **隐式锁的逻辑过程如下：**  
> **A.** InnoDB的每条记录中都一个隐含的trx\_id字段，这个字段存在于聚簇索引的B+Tree中。  
> **B.** 在操作一条记录前，首先根据记录中的trx\_id检查该事务是否是活动的事务(未提交或回滚)。如果是活动的事务，首先将 隐式锁 转换为 显式锁 (就是为该事务添加一个锁)。  
> **C.** 检查是否有锁冲突，如果有冲突，创建锁，并设置为waiting状态。如果没有冲突不加锁，跳到E。  
> **D.** 等待加锁成功，被唤醒，或者超时。  
> **E.** 写数据，并将自己的trx\_id写入trx\_id字段。

### 2. 显式锁 ###

![387cb09e700a49c1aeb7a1daf66f3451.png][]

## 5、其它锁之：全局锁 ##

> 全局锁就是对 整个数据库实例 加锁。当你需要让整个库处于 只读状态 的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。全局锁的典型使用 场景 是：做 全库逻辑备份 。

全局锁的命令：Flush tables with read lock

## 6、其它锁之：死锁 ##

![e6a9acfc57e94438aca59ca678230161.png][]

![7c113e1b50bb4dca91b2a37d251ea7a0.png][]

# 四、锁的内存结构 #

--------------------

**InnoDB 存储引擎中的 锁结构 如下：**

![fabcbb2646444bc2b4aecf0f8a0a3964.png][]

**结构解析：**

![0bff7b76a42f4b1bad1f8bb44c7eae3b.png][]

![28cfe3650dcc4393890616515afdecb7.png][]

![2eec4147bd2944f1a44a9015d7d6e43c.png][]

# 五、锁监控 #

--------------------

![b8bc40b025774514944d23cc3b034df0.png][]

![deaaa0e120154f2c88a68c11acab9127.png][]

# 六、附录 #

--------------------

**间隙锁加锁规则（共11个案例）**

**---见课件笔记**

高级篇笔记PDF自取

链接：[https://pan.baidu.com/s/1pVqrTwIZFoED77i-EFmw6g?pwd=3333 ][https_pan.baidu.com_s_1pVqrTwIZFoED77i-EFmw6g_pwd_3333]  
提取码：3333

[Link 1]: https://so.csdn.net/so/search?q=%E5%B0%9A%E7%A1%85%E8%B0%B7&spm=1001.2101.3001.7020
[MySQL]: https://so.csdn.net/so/search?q=MySQL%E9%AB%98%E7%BA%A7&spm=1001.2101.3001.7020
[e6d12ae29df34d85b3d69782f68ca0b1.png]: https://img-blog.csdnimg.cn/e6d12ae29df34d85b3d69782f68ca0b1.png
[8ea5d993210343bf956f4716e355791c.png]: https://img-blog.csdnimg.cn/8ea5d993210343bf956f4716e355791c.png
[240aa856aaec43e4945145ca039498f3.png]: https://img-blog.csdnimg.cn/240aa856aaec43e4945145ca039498f3.png
[065a779a228e4d40b789a01f2592d152.png]: https://img-blog.csdnimg.cn/065a779a228e4d40b789a01f2592d152.png
[ec6b59a650f8432e82dbae918852ab59.png]: https://img-blog.csdnimg.cn/ec6b59a650f8432e82dbae918852ab59.png
[2741eb862eac4e07be4d3e686bfd099c.png]: https://img-blog.csdnimg.cn/2741eb862eac4e07be4d3e686bfd099c.png
[0134ae0327874d7c94b1d1979e3ac5c0.png]: https://img-blog.csdnimg.cn/0134ae0327874d7c94b1d1979e3ac5c0.png
[30fb745117524928891ed768cd51542c.png]: https://img-blog.csdnimg.cn/30fb745117524928891ed768cd51542c.png
[17aa56a132e54a30beebd25e71965f64.png]: https://img-blog.csdnimg.cn/17aa56a132e54a30beebd25e71965f64.png
[89e7487b35564c35a8abeb32c5ad0e29.png]: https://img-blog.csdnimg.cn/89e7487b35564c35a8abeb32c5ad0e29.png
[686368e874114d02a088a4b9630cb3fd.png]: https://img-blog.csdnimg.cn/686368e874114d02a088a4b9630cb3fd.png
[7e8f4b9b09c44449a4d0e4d9f54265d2.png]: https://img-blog.csdnimg.cn/7e8f4b9b09c44449a4d0e4d9f54265d2.png
[c2af7a8cdeb645998c8c363d76b4b39f.png]: https://img-blog.csdnimg.cn/c2af7a8cdeb645998c8c363d76b4b39f.png
[d1113effdb644d34b97676c5afd714bb.png]: https://img-blog.csdnimg.cn/d1113effdb644d34b97676c5afd714bb.png
[87149d2d94d542c7bd72cecf99bfa37b.png]: https://img-blog.csdnimg.cn/87149d2d94d542c7bd72cecf99bfa37b.png
[1846dcf2f7d447b197de179f8c7e596d.png]: https://img-blog.csdnimg.cn/1846dcf2f7d447b197de179f8c7e596d.png
[548ba3e8e0834783aded613dbd5e1157.png]: https://img-blog.csdnimg.cn/548ba3e8e0834783aded613dbd5e1157.png
[80745624ac2d4f7c859141deb93c2faf.png]: https://img-blog.csdnimg.cn/80745624ac2d4f7c859141deb93c2faf.png
[a091522a7e394a29905137f2d90b23f7.png]: https://img-blog.csdnimg.cn/a091522a7e394a29905137f2d90b23f7.png
[39806482cd7c4870853b66e5c9d3d06e.png]: https://img-blog.csdnimg.cn/39806482cd7c4870853b66e5c9d3d06e.png
[55a8e94e40254018b3c1f11e0e3829b2.png]: https://img-blog.csdnimg.cn/55a8e94e40254018b3c1f11e0e3829b2.png
[387cb09e700a49c1aeb7a1daf66f3451.png]: https://img-blog.csdnimg.cn/387cb09e700a49c1aeb7a1daf66f3451.png
[e6a9acfc57e94438aca59ca678230161.png]: https://img-blog.csdnimg.cn/e6a9acfc57e94438aca59ca678230161.png
[7c113e1b50bb4dca91b2a37d251ea7a0.png]: https://img-blog.csdnimg.cn/7c113e1b50bb4dca91b2a37d251ea7a0.png
[fabcbb2646444bc2b4aecf0f8a0a3964.png]: https://img-blog.csdnimg.cn/fabcbb2646444bc2b4aecf0f8a0a3964.png
[0bff7b76a42f4b1bad1f8bb44c7eae3b.png]: https://img-blog.csdnimg.cn/0bff7b76a42f4b1bad1f8bb44c7eae3b.png
[28cfe3650dcc4393890616515afdecb7.png]: https://img-blog.csdnimg.cn/28cfe3650dcc4393890616515afdecb7.png
[2eec4147bd2944f1a44a9015d7d6e43c.png]: https://img-blog.csdnimg.cn/2eec4147bd2944f1a44a9015d7d6e43c.png
[b8bc40b025774514944d23cc3b034df0.png]: https://img-blog.csdnimg.cn/b8bc40b025774514944d23cc3b034df0.png
[deaaa0e120154f2c88a68c11acab9127.png]: https://img-blog.csdnimg.cn/deaaa0e120154f2c88a68c11acab9127.png
[https_pan.baidu.com_s_1pVqrTwIZFoED77i-EFmw6g_pwd_3333]: https://pan.baidu.com/s/1pVqrTwIZFoED77i-EFmw6g?pwd=3333%C2%A0