MySQL高级篇笔记（四）锁机制

最新推荐文章于 2024-04-24 14:48:34 发布

好运的云

最新推荐文章于 2024-04-24 14:48:34 发布

阅读量142

点赞数

分类专栏： MySQL 文章标签： mysql

本文链接：https://blog.csdn.net/heyyun/article/details/108433324

版权

MySQL 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

四、MySQL锁机制

1. 概述

1.1. 定义

锁是计算机协调多个进程或线程并发访问某一资源的机制。

在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。

1.2. 生活例子

打个比方，我们到淘宝上买一件商品，商品只有一件库存，这个时候如果还有另一个人买，
那么如何解决是你买到还是另一个人买到的问题？

这里肯定要用到事务，我们先从库存表中取出物品数量，然后插入订单，付款后插入付款表信息，
然后更新商品数量。在这个过程中，使用锁可以对有限的资源进行保护，解决隔离和并发的矛盾。

2. 锁的分类

2.1. 从对数据操作的类型分类

读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会相互影响。如果事务T对数据A加上读锁，那么其他事务只能对数据A再加读锁，不能加写锁。获取到读锁的事务只能读数据，不能写数据。
写锁（排他锁）：当前写操作没有完成前，它会阻断其他写锁和读锁。

2.2. 从对数据操作的颗粒度分类

为了尽可能提高数据库的并发度，每次锁定的数据范围越小越好，理论上只需要锁定当前操作的数据，这样会得到最高的并发度，但是管理锁是很耗资源的事情（涉及到锁的获取、检查、释放锁等动作），因此数据库需要在高并发响应和系统性能两方面进行平衡，这样就产生了“颗粒度”的概念。

一种提高共享资源并发性的方式是让锁定对象更有选择性，尽量只锁定需要修改的部分，而不是所有的资源。更理想的是，只会对修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可。

表锁
行锁

3. 三锁

3.1. 表锁（偏读）

3.1.1. 特点

偏向MyISAM存储引擎，加锁快，开销小，无死锁。锁的粒度比较大，发生锁冲突的概率最高，并发度最低。

3.1.2. 案例分析

建表SQL

create table mylock( 
 id int not null primary key auto_increment， 
 name varchar(20) 
) engine myisam; 
 
insert into mylock(name) values('a'); 
insert into mylock(name) values('b'); 
insert into mylock(name) values('c'); 
insert into mylock(name) values('d'); 
insert into mylock(name) values('e'); 
 
select * from mylock;

手动增加表锁

lock table 表名字1 read(write)， 表名字2 read(write)，其它 ;

查看表上加过的锁

show open tables;

in_use列为1时，表示有锁

释放表锁

unlock tables;

加读锁

为mylock表加read锁，分别打开两个命令行session1和session2对同一个表进行操作。

在这里插入图片描述

加入读锁之后：
session1可以读已经加锁的表，但是不能改或者读其他没加锁的表，因为前面"欠的账还没有清"。
session2可以查看已锁定的表，可以查看其他未锁定的表，但是操作加锁的表会阻塞等待，会导致系统性能下降。

加写锁

mylock write(MyISAM)

在这里插入图片描述

注意session1去读取其他的表同样会报错，原因同读锁“欠的账还没有还清”

结论

MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行增删改操作前，会自动给涉及的表加写锁。
MySQL的表级锁有两种模式：

表共享读锁（Table Read Lock）
表独占写锁（Table Write Lock）

结合上表，所以对于MyISAM表进行操作，会有以下情况：

加读锁，不会阻塞其他进程对加读锁的这一张表的读操作，但会阻塞对这张表的写操作。当读锁释放后，才会执行其他其他线程的写操作。
加写锁，会阻塞其他进程对加写锁的这张表的读和写操作，只有当写锁释放后，其他进程的读写操作才能正常执行

简而言之：读锁会阻塞写，写锁会阻塞读和写。

3.1.3. 分析表锁定

可以通过检查 table_ locks waited和 table_ locks_immediate状态变量来分析系统上的表锁定

show status like ‘table%’

在这里插入图片描述
这里有两个状态变量记录 MySQL内部表级锁定的情况，两个变量说明如下:

Table_ locks_ immediate：产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁值加1;
Table_ locks_waited出现表级锁定争用而发生等待的次数(不能立即获取锁的次数，每等待一次锁值加1)，此值高则说明存在着较严重的表级锁争用情况。

此外，MyISAM的读写锁调度是写优先，这也是MyISAM不适合做写为主的引擎，因为写锁后，其他线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永远阻塞，所以表锁偏读。

3.2. 行锁（偏写）

3.2.1. 行锁特点

偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。

3.2.2. 事务特点

事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，通常简称为事务的ACID属性。

原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。
隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。
持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。

3.2.3. 并发处理事务带来的问题

更新丢失(Lost Update)

当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题，最后的更新覆盖了由其他事务所做的更新。

例如，两个程序员修改同一java文件。每程序员独立地更改其副本，然后保存更改后的副本，这样就覆盖了原始文档。最后保存其更改副本的编辑人员覆盖前一个程序员所做的更改。

如果在一个程序员完成并提交事务之前，另一个程序员不能访问同一文件，则可避免此问题。

脏读(Dirty Reads)

一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象地叫做”脏读”。

一句话：事务A读取到了事务B 已修改但尚未提交 的的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取
的数据无效，不符合一致性要求。

不可重复读(Non-Repeatable Reads)

在一个事务内，多次读同一个数据。在这个事务还没有结束时，另一个事务也访问该同一数据。那么，在第一个事务的两次读数据之间。由于第二个事务的修改，那么第一个事务读到的数据可能不一样，这样就发生了在一个事务内两次读到的数据是不一样的，因此称为不可重复读，即原始读取不可重复。

一句话：一个事务范围内两个相同的查询却返回了不同数据。

幻读(Phantom Reads)

一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。

一句话：事务A读取到了事务B提交的新增数据，不符合隔离性。

3.2.4. 事务隔离级别

“脏读”、“不可重复读”和“幻读”，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。

在这里插入图片描述

数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大，因为事务隔离实质上就是使事务在一定程度上 “串行化”进行，这显然与“并发”是矛盾的。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读”和“幻读”并不敏感，可能更关心数据并发访问的能力。

查看当前数据库的事务隔离级别：

show variables like 'tx_isolation'

从图中可以看到MySQL默认的隔离级别是可重复读，也就说明MYSQL默认能够解决脏读和不可重复读的问题，但是不能解决幻读的问题。

3.2.5. 案例分析

建表SQL（注意engine=innodb）

create table test_innodb_lock (a int(11),b varchar(16)) engine=innodb; 


insert into test_innodb_lock values(1,'b2'); 
insert into test_innodb_lock values(3,'3'); 
insert into test_innodb_lock values(4,'4000'); 
insert into test_innodb_lock values(5,'5000'); 
insert into test_innodb_lock values(6,'6000'); 
insert into test_innodb_lock values(7,'7000'); 
insert into test_innodb_lock values(8,'8000'); 
insert into test_innodb_lock values(9,'9000'); 
insert into test_innodb_lock values(1,'b1'); 


create index test_innodb_a_ind on test_innodb_lock(a); 


create index test_innodb_lock_b_ind on test_innodb_lock(b); 


select * from test_innodb_lock;

行锁定基本演示

在这里插入图片描述

为了测试行锁，先将自动提交关闭，每次都需要手动提交，set autocommit = 0

因为关闭了自动提交，所以session2没有读到sessoin1中的修改，两边都需要进行commit，按照正常的如果sessioin1关闭了自动提交，session2没有关闭自动提交的话，只需要session1执行commit，但是这里的session2也是关闭自动提交的，所以session2也应该执行commit。

session1操作4005行， session2操作 9001 行，双方互不影响，都能成功。

无索引行锁升级为表锁（索引失效）

在这里插入图片描述

原因分析：b是varchar类型，这里设置为4000，在mysql底层会自动做一次转换，转换为varchar，所以索引失效，行锁变成了表锁，导致seesion1操作a=41，session2操作a=9，session2会阻塞。所以生产环境中一定注意varchar加”“。

select也可以加锁

（1）读锁：select …lock in share mode

（2）写锁：select… for update

在查询语句后面增加 FOR UPDATE ，Mysql会对查询结果中的每行都加排他锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请排他锁，否则会被阻塞。

间隙锁的危害

在这里插入图片描述

注意原表中是没有a=2的，这个时候操作session1，session2设置a=2的值会阻塞，只有当session1 commit之后，session2才能操作成功。session1用的范围查询，a中1~6 虽然没有2，但是也认为2在里面，也给锁住，session2操作的时候就会阻塞。

这就是MYSQL，宁可错杀一千，也不放过一个。

什么是间隙锁？

当我们使用范围条件而不是相等条件去检索数据时，并请求共享锁或者排他锁时，Innodb会给符合条件的数据记录的索引项加锁；对于键值不存在但是满足范围条件的记录，叫做“间隙”（GAP）

Innodb会给这个间隙加锁，这个锁机制就是所谓的”间隙锁“（GAP LOCK）

间隙锁的危害

因为在Query执行过程中，MYSQL会锁定整个范围内的所有索引键值，即使这个键值不存在。

间隙锁有一个致命的弱点，就是当锁定一个范围内的键值时，即使某个键值不存在也会被锁定，这就造成了在锁定的时候无法插入锁定范围内的任何数据，在某些场景下这可能会对性能造成极大的危害。

案例结论

Innodb存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。当系统并发量较高的时候，Innodb的整体性能和MyISAM相比就会有比较明显的优势了。

但是，Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候，可能会让Innodb的整体性能表现不仅不能比MyISAM高，甚至可能会更差。

3.2.6. 行锁分析

如何分析行锁定？

通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况

show status like 'innodb_row_lock%';

变量分析

对各个状态量的说明如下：

Innodb_row_lock_current_waits：当前正在等待锁定的数量
Innodb_row_lock_time：从系统启动到现在锁定总时间长度
Innodb_row_lock_time_avg：每次等待所花平均时间
Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花的时间
Innodb_row_lock_waits：系统启动后到现在总共等待的次数
对于这5个状态变量，比较重要的主要是

Innodb_row_lock_time_avg（等待平均时长）
Innodb_row_lock_waits（等待总次数）
Innodb_row_lock_time（等待总时长）

当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。

最后可以通过SELECT * FROM information_schema.INNODB_TRX\G;来查询正在被锁阻塞的sql语句。

3.2.7. 面试题：如何锁定一行

3.2.8. 行锁总结

尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁。
尽可能较少检索条件，避免间隙锁。
尽量控制事务大小，减少锁定资源量和时间长度。
锁住某行后，尽量不要去调别的行或表，赶紧处理被锁住的行然后释放掉锁。
涉及相同表的事务，对于调用表的顺序尽量保持一致。
在业务环境允许的情况下,尽可能低级别事务隔离。

3.3. 页锁（了解）

开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

3.2.7. 面试题：如何锁定一行

[外链图片转存中…(img-neE4S2TU-1599381657364)]

3.2.8. 行锁总结

尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁。
尽可能较少检索条件，避免间隙锁。
尽量控制事务大小，减少锁定资源量和时间长度。
锁住某行后，尽量不要去调别的行或表，赶紧处理被锁住的行然后释放掉锁。
涉及相同表的事务，对于调用表的顺序尽量保持一致。
在业务环境允许的情况下,尽可能低级别事务隔离。

3.3. 页锁（了解）

开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

好运的云

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
1
评论
MySQL高级篇笔记（四）锁机制

文章目录四、MySQL锁机制1. 概述1.1. 定义1.2. 生活例子2. 锁的分类2.1. 从对数据操作的类型分类2.2. 从对数据操作的颗粒度分类3. 三锁3.1. 表锁（偏读）3.1.1. 特点3.1.2. 案例分析3.1.3. 分析表锁定3.2. 行锁（偏写）3.2.1. 行锁特点3.2.2. 事务特点3.2.3. 并发处理事务带来的问题3.2.4. 事务隔离级别3.2.5. 案例分析3.2.6. 行锁分析3.2.7. 面试题：如何锁定一行3.2.8. 行锁总结3.3. 页锁（了解）3.2.7. 面
复制链接

扫一扫