【MySQL】锁详解——从结构分类到适用场景-Toy模板网

这篇具有很好参考价值的文章主要介绍了【MySQL】锁详解——从结构分类到适用场景。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

我们要学习锁首先要了解下我们想了解的锁到底是什么🤔

而在MySQL中给某个数据加锁的本质其实就是在内存中创建一个锁结构与之关联，而这个锁结构就是我们常提到的MySQL的锁🔒

那么接下来的问题就是，这个锁结构长啥样呢？

锁的内部结构（InnoDB）

一张图详解锁结构(￣∇￣)/

【MySQL】锁详解——从结构分类到适用场景

为了节约资源，并非每个锁都有一个单独的锁结构与之对应，符合如下条件的记录就会放在同一个锁结构中

在同一个事务/页面中进行的加锁操作
加锁的类型一样
等待状态一样

锁的分类

按操作方式
- 读锁/共享锁/S（Share Lock）
- 写锁/排他锁/X（Exclusive Lock）
按锁粒度（Lock Granularity）
- 全局锁
- 表级锁（Table Lock）
  - 表级别的共享锁和排他锁
  - 意向锁（Intention Lock）
  - 自增锁（AUTO-INC）
  - 元数据锁（MDL）
- 页级锁
- 行级锁
  - 记录锁（Record Locks）
  - 间隙锁（Gap Locks）
  - 临键锁（Next-Key Locks）
  - 插入意向锁（Insert Intention Locks）
按思维方式/设计思想
- 乐观锁（Optimistic Concurrency Control）
- 悲观锁（Pessimistic Concurrency Control）
按加锁方式
- 隐式锁
- 显式锁

共享锁 vs 排他锁

并发事务中"读-读"的情况一般不会引起什么问题，一般需要解决的就是对于"写-写"和"读-写"/"写-读"引起一些问题，主要有两种解决方式：加锁，或者需MVCC

既要允许"读-读"情况不受影响，又要使"写-写"、"读-写"或"写-读"情况中的操作相互阻塞，所以MySQL实现一个由两种类型的锁组成的锁系统来解决

这两种类型的锁通常被称为共享锁（Shared Lock，S Lock）和排他锁（Exclusive Lock，X Lock），也叫读锁（readlock）和写锁（write lock ）

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

一句话概括就是，不同事务中，只有都是共享锁才互不影响不会阻塞，但凡有一个事务有排他锁，都会阻塞，对于InnoDB引擎来说，共享锁和排他锁可以加在表上，也可以加在行上

如何加锁

加共享锁
- SQL语句 + "LOCK IN SHARE MODE" / "FOR SHARE";
加排他锁
- SQL语句 + "FOR UPDATE";

需要注意的是：

读操作（SELECT）可以加共享锁，也可以加排他锁
写操作（DELETE、UPDATE、INSERT）只能加排他锁
- INSERT
  - MySQL通过"隐式锁"来维护
- DELETE
  - B+树上定位 -> 获取X锁 -> 执行delete mark操作
- UPDATE
  - 修改键值：DELETE操作 + INSERT操作
  - 不修改键值：
    1. 不修改存储空间：B+树上定位 -> 获取X锁 -> 修改
    2. 修改存储空间：B+树上定位 -> 获取X锁 -> 删除原纪录（移入垃圾链表） -> 插入新纪录（INSERT操作）

补充：MySQL 8.0 新特性

nowait
- 查询的数据已经加锁，立刻返回报错
skip locked
- 立刻返回未被锁定的行

全局锁 vs 表级锁 vs 页级锁 vs 行级锁

数据库的并发度和锁的粒度息息相关，锁的粒度越小，并发度越高，但也越耗资源（锁的获取、检查、释放等操作），影响系统性能，因而我们需要根据实际的业务场景，在高并发响应与系统性能之间进行平衡

全局锁

对整个数据库实例进行加锁，加锁后整个数据库处于只读状态，命令如下：

Flush tables with read lock

表锁

开销小，但并发性较差
可以避免死锁

不与行级锁冲突的表级锁：意向锁

主要用于在已经加了行级锁后，会在上一层记录中自动加一个意向锁，用于判断当前数据页或者数据表是否被加过锁，意向共享锁和意向排他锁之间是任意组合都是相互兼容的，但是与普通的共享锁/排他锁之间，只有意向共享锁与普通共享锁兼容，其余都互斥

具体使用意向共享锁，还是意向排他锁，要根据行级锁（与行级锁一致）

意向锁之间不互斥
意向锁与行级锁不互斥，与表级锁互斥
意向锁在保证高并发的前提下，实现了行锁与表锁共存，并且满足事务隔离性的要求

自增锁

建表字段中如果包含"AUTO_INCREMENT"关键字，每当插入操作时，就要对自增锁进行竞争，以保证主键唯一且单调递增

首先，插入数据的模式有3种：

简单插入（Simple inserts）
事先明确插入的数量
批量插入（Bulk inserts）
基于现有的表进行插入（事先并明确插入的数量）
混合模式插入（Mixed-mode inserts）
插入的数据有的有主键，有的没主键

主要有3种模式

"传统"锁定模式（并发性较差）
- innodb_autoinc_lock_mode=0
"连续"锁定模式（8.0前默认）
innodb_autoinc_lock_mode=1
"交错"锁定模式（8.0后默认）
innodb_autoinc_lock_mode=2

元数据锁（MDL）

可以通过下面👇代码查看当前执行的process信息

show processlist;

如果想查看在等待哪把锁，可以重点关注下State字段

页锁

开销、粒度、并发度介于表锁和行锁之间
也会出现死锁
每个层级的锁数量是有限制的（锁会占用内存空间），锁空间的大小是有限制的，某个层达到阈值后就会进行锁升级（用更大力度的锁代替多个较小粒度的锁）
- 比如一张表中出现大量DELETE操作时，会锁表

行锁（InnoDB）

行锁又称记录锁，锁的是某一行数据

MySQL的服务层并没有实现行锁机制，行锁是在存储引擎层实现的

优点
- 锁粒度小，发生锁冲突概率低，可实现的并发度高
缺点
- 锁的开销较大，加锁较慢，会出现死锁

记录锁

可参照读锁和写锁理解，只不过粒度是行，只有操作相同的行才有影响

间隙锁（解决幻读问题）

在MySQL的可重复读的隔离级别下，可以解决幻读问题

因为在一开始进行读取操作的时候，我们并不知道会产生幻影数据的主键是多少（还不存在），因而无法使用记录锁事先锁定那一行，间隙锁会阻塞当前记录和其前一条记录之间的插入操作。

对于间隙锁很多文章都有小部分出入，我们就以官网为准

MySQL :: MySQL 8.0 Reference Manual :: 15.7.1 InnoDB Locking

【MySQL】锁详解——从结构分类到适用场景

这段话中提到的比较重要的部分就是说间隙锁是在索引记录之间的间隙上的锁，或者是在第一条索引记录之前或最后一条索引记录之后的间隙上的锁，对于使用唯一索引锁定行以搜索唯一行的语句，不需要间隙锁定（这不包括搜索条件只包括多列唯一索引的某些列的情况；在这种情况下，确实会发生间隙锁定）

例如，如果该列具有唯一索引，则以下语句仅使用id一个索引记录锁定值为 100 的行id，其他会话是否在前面的间隙中插入行并不重要：

SELECT * FROM child WHERE id = 100;

如果id未索引或具有非唯一索引，则该语句会锁定前面的间隙

临键锁

一句话理解～就是记录锁+间隙锁（不愧是我(*≧ω≦)/），如果还是不太明白这些🔒的锁定范围，可以移步博文

【MySQL】记录锁？间隙锁？临键锁？到底锁了些什么？这一篇帮你捋清楚(￣∇￣)/_AQin1012的博客-CSDN博客

插入意向锁

获取锁失败的事务，开始等待的事务的其锁的类型就是插入意向锁，插入意向锁并不会阻止别的事务继续获取该记录上任何类型的锁

乐观锁 vs 悲观锁

悲观锁

悲观锁是通过数据库自身的锁机制来实现，从而保证致据操作的排它性。

悲观锁总是假设最坏的情况，认为每次去查数据的时候都会被别人修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）比收如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当其他线程想要访问数据时，都需要阻塞挂起

如果在SELECT语句上加悲观锁，在这条语句执行过程中所有扫描的行都会被锁上，因此在MySQL中使用悲观锁需要确定必须使用了索引，不然会全表扫描，把整张表都锁上