【MySQL系统学习专栏】- 锁机制

最新推荐文章于 2024-07-24 16:20:20 发布

陈七.

最新推荐文章于 2024-07-24 16:20:20 发布

阅读量106

点赞数 3

分类专栏：数据库文章标签： mysql 学习数据库

本文链接：https://blog.csdn.net/qq_45491628/article/details/129455911

版权

数据库专栏收录该内容

16 篇文章 3 订阅

订阅专栏

文章目录

前言
一、锁机制介绍
二、锁的划分
三、死锁现象
四、MVCC并发控制
五、总结

前言

事务与锁机制是密不可分的，事务的隔离性通过事务的隔离级别来定义，并用锁机制来保证写操作的隔离性。锁机制是在事务并发控制中一个重要的模块

在上一篇博客：【MySQL系统学习专栏】- 事务处理中提到，SERIALIZABLE 就是使用锁独占方式来确保只有一个版本时事务被隔离，此隔离级别也解决了幻读的问题，那么在这一篇博文中，我们就来聊一聊MySQL的锁机制吧。

一、锁机制介绍

锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除了传统的计算资源（CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题。为了处理并发访问过程中出现的问题，并且合理的控制资源的访问规则，就设计出了MySQL的锁机制。

二、锁的划分

按照锁的粒度划分：行锁、表锁、页锁、全局锁
按照锁的使用方式划分：共享锁、排它锁（悲观锁的一种实现）也叫读锁和写锁
还有两种思想上的锁：悲观锁、乐观锁。
InnoDB中有几种行级锁类型：Record Lock、Gap Lock、Next-key Lock
为了解决幻读的问题，又引入了间隙锁的概念

MySQL的锁机制最显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。

（一）行锁

InnoDB存储引擎就是采用了行级锁，并且支持事务

行级锁按照使用方式分为共享锁和排他锁。另外，为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁，这两种意向锁都属于表锁：意向共享锁和意向排他锁

行锁实现方式：

输入：

共享锁

SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE

排他锁

SELECT * FROM table_name WHERE ... FOR UPDATE

意向锁是InooDB自动加的，不需要用户干预。

（二）表锁

MyISAM存储引擎只支持表锁，这也是MySQL开始几个版本中唯一支持的锁类型。随着应用对事务完整性和并发现要求的不断提高，，MySQL才开始开发基于事务的存储引擎，后来慢慢出现了支持页锁的BDB存储引擎和支持行锁的InnoDB存储引擎。但是MyISAM的表锁依然是使用最为广泛的锁类型

表锁按照使用方式也可分为：共享锁，排他锁。

表锁实现方式：

输入：

共享锁

LOCK TABLE table_name [ AS alias_name ] READ

排他锁

LOCK TABLE table_name [AS alias_name][ LOW_PRIORITY ] WRITE

解锁

unlock tables;

（三）页锁和全局锁

1.页锁

页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。BDB存储引擎支持页级锁

BDB已经被InnoDB取代，即将成为历史，在此就不做进一步的讨论了。

2.全局锁

除了行锁，表锁，页锁外，这里还补充一种全局锁，这种锁的范围最大。
全局锁就是对整个数据库实例加锁。MySQL提供了一个加全局读锁的方法，命令是 Flush tables with read lock (FTWRL)。当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。

全局锁的典型使用场景是，做全库逻辑备份。全也就是把整库每个表都select出来存成文本。

（五）间隙锁

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙(GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的Next-Key锁。

举例来说，假如emp表中只有101条记录，其empid的值分别是1、2…100、101，下面的SQL:
Select * from emp where empid >100 for update;
是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101(这些记录并不存在)的“间隙”加锁。
InnoDB使用Next-Key锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求，对于上面的例子，要是不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；另一方面，是为了满足其恢复和复制的需要。

（六）悲观锁和乐观锁

1.悲观锁

在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作对某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。

悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度(悲观)，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）

mysql中实现悲观锁的具体流程：

在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）
如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。
如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。

总而言之就是一句话：mysql中悲观锁的实现是通过排他锁来实现的

2.乐观锁

在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。

乐观锁（ Optimistic Locking ）相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。

mysql实现乐观锁一般来说有2种方式：

使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。

一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。

当提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，就进行更新操作，否则认为是过期数据，正在提交的事务会进行回滚。
第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）, 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致就更新，否则就是版本冲突。

三、死锁现象

死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时，就可能会产生死锁。多个事务同时锁定同一个资源时，也会产生死锁。

四、MVCC并发控制

多版本并发控制（MVCC）是一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。这样在读操作不用阻塞写操作，写操作不用阻塞读操作的同时，避免了脏读和不可重复读

serializable ，使用锁独占方式来确保只有一个版本时事务被隔离，因此锁可以理解为单版本控制。

五、总结

MySQL这3种锁的特性可大致归纳如下。
表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

从上述特点可见，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适！仅从锁的角度来说：表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用。