Mysql的锁相关的知识

秒速五厘米 2023-10-06 16:54 50阅读 0赞

**目录**

一、数据库的锁和事务的隔离级别

行锁（Record lock）

间隙锁（Gap lock）

快照读：

当前读：

意向锁：

MVCC：快照读（Snapshot Read）与当前读（Current Read）

事务的四种隔离级别

数据库锁类型

锁定方式

二、数据库死锁定义及其产生的必要条件

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

## 一、数据库的锁和事务的隔离级别 ##

### 行锁（Record lock） ###

单条索引记录上加锁，record lock锁住的永远是索引，而非记录本身，即使该表上没有任何索引，那么innodb会在后台创建一个隐藏的聚集主键索引，那么锁住的就是这个隐藏的聚集主键索引。所以说当一条sql没有走任何索引时，那么将会在每一条聚集索引后面加X锁，这个类似于表锁，但原理上和表锁应该是完全不同的。

###    间隙锁（Gap lock） ###

在索引记录之间的间隙中加锁，或者是在某一条索引记录之前或者之后加锁，并不包括该索引记录本身。gap lock的机制主要是解决可重复读模式下的幻读问题，关于幻读的演示和gap锁如何解决了幻读。关于这一块，先给出几个定义

###    快照读： ###

简单的select操作，没有lock in share mode或for update，快照读不会加任何的锁，而且由于mysql的一致性非锁定读的机制存在，任何快照读也不会被阻塞。但是如果事务的隔离级别是SERIALIZABLE的话，那么快照读也会被加上共享的next-key锁，本文不对SERIALIZABLE隔离级别做叙述。

### 当前读： ###

官方文档的术语叫locking read，也就是insert，update，delete,select..in share mode和select..for update,当前读会在所有扫描到的索引记录上加锁，不管它后面的where条件到底有没有命中对应的行记录。当前读可能会引起死锁。

### 意向锁： ###

innodb的意向锁主要用户多粒度的锁并存的情况。比如事务A要在一个表上加S锁，如果表中的一行已被事务B加了X锁，那么该锁的申请也应被阻塞。如果表中的数据很多，逐行检查锁标志的开销将很大，系统的性能将会受到影响。为了解决这个问题，可以在表级上引入新的锁类型来表示其所属行的加锁情况，这就引出了“意向锁”的概念。举个例子，如果表中记录1亿，事务A把其中有几条记录上了行锁了，这时事务B需要给这个表加表级锁，如果没有意向锁的话，那就要去表中查找这一亿条记录是否上锁了。如果存在意向锁，那么假如事务Ａ在更新一条记录之前，先加意向锁，再加Ｘ锁，事务B先检查该表上是否存在意向锁，存在的意向锁是否与自己准备加的锁冲突，如果有冲突，则等待直到事务Ａ释放，而无须逐条记录去检测。事务Ｂ更新表时，其实无须知道到底哪一行被锁了，它只要知道反正有一行被锁了就行了。  
说白了意向锁的主要作用是处理行锁和表锁之间的矛盾，能够显示“某个事务正在某一行上持有了锁，或者准备去持有锁”

### MVCC：快照读（**Snapshot Read**）与当前读（**Current Read**） ###

MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC ([Multi-Version Concurrency Control][]) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。其最大的优点是：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。

MVCC读取数据的方式分为快照读和当前读两种方式。快照读：读取指定版本，不需要加锁，如简单的select操作；当前读：读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。如插入、更新、删除操作，均需要进行加锁。之所以将这些操作归为当前读，用更新操作举例，在进行更新操作前，首先会读取当前的待更新数据库字段的值进行返回并加锁（当前读），待mysql收到这个加锁记录后，才会发起一个update的操作，更新该记录。删除操作同理，插入操作稍有不同，简单地说在执行插入前可能会触发唯一键检查操作，也会进行一个当前读。

mysql把每个操作都定义成一个事务，每开启一个事务，系统的事务版本号自动递增。每行记录都有两个隐藏列：创建版本号和删除版本号。

select：事务每次只能读到创建版本号小于等于此次系统版本号的记录，同时（且）行的删除版本号不存在或者大于当前事务的版本号。

update：插入一条新记录，并把当前系统版本号作为行记录的版本号，同时保存当前系统版本号到原有的行作为删除版本号。

delete：把当前系统版本号作为行记录的删除版本号。

insert：把当前系统版本号作为行记录的版本号。

### 事务的四种隔离级别 ###

在数据库操作中，为了有效保证并发读取数据的正确性，提出的事务隔离级别。数据库锁也是为了构建这些隔离级别存在的。

<table> 
 <thead> 
  <tr> 
   <th> <p>隔离级别</p> </th> 
   <th> <p>脏读（Dirty Read）</p> </th> 
   <th> <p>不可重复读（NonRepeatable Read）</p> </th> 
   <th> <p>幻读（Phantom Read）</p> </th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>未提交读（Read uncommitted）</td> 
   <td>可能</td> 
   <td>可能</td> 
   <td>可能</td> 
  </tr> 
  <tr> 
   <td>已提交读（Read committed）</td> 
   <td>不可能</td> 
   <td>可能</td> 
   <td>可能</td> 
  </tr> 
  <tr> 
   <td>可重复读（Repeatable read）</td> 
   <td>不可能</td> 
   <td>不可能</td> 
   <td>可能</td> 
  </tr> 
  <tr> 
   <td>可串行化（Serializable ）</td> 
   <td>不可能</td> 
   <td>不可能</td> 
   <td>不可能</td> 
  </tr> 
 </tbody> 
</table>

*  未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据
 *  提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)
 *  可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读
 *  串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞

### 数据库锁类型 ###

根据对资源操作的不同，对资源锁定的级别也有所不同。MySQL InnoDB存储引擎的锁类型分为以下几种。

<table> 
 <thead> 
  <tr> 
   <th> <p>锁类型</p> </th> 
   <th> <p>描述</p> </th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>共享锁(S)</td> 
   <td>允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。</td> 
  </tr> 
  <tr> 
   <td>排他锁(X)</td> 
   <td>允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。</td> 
  </tr> 
  <tr> 
   <td>意向共享锁(IS)</td> 
   <td>事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。</td> 
  </tr> 
  <tr> 
   <td>意向排他锁(IX)</td> 
   <td>事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。</td> 
  </tr> 
 </tbody> 
</table>

上述锁类型之间的兼容关系如下

如果一个事务请求的锁模式与当前的锁兼容，InnoDB就将请求的锁授予该事务；反之，如果两者不兼容，该事务就要等待锁释放。  
意向锁是InnoDB自动加的，不需用户干预。对于当前读操作，InnoDB会自动给涉及数据集加排他锁（X)；对于快照读操作，InnoDB不会加任何锁；事务可以通过以下语句显示给记录集加共享锁或排他锁。  
共享锁（S）：SELECT \* FROM table\_name WHERE ... LOCK IN SHARE MODE。  
排他锁（X)：SELECT \* FROM table\_name WHERE ... FOR UPDATE。  
用SELECT ... IN SHARE MODE获得共享锁，主要用在需要数据依存关系时来确认某行记录是否存在，并确保没有人对这个记录进行UPDATE或者DELETE操作。但是如果当前事务也需要对该记录进行更新操作，则很有可能造成死锁，对于锁定行记录后需要进行更新操作的应用，应该使用SELECT... FOR UPDATE方式获得排他锁。

### 锁定方式 ###

mysql innodb支持三种行锁定方式：

行锁（Record Lock）:锁直接加在索引记录上面，锁住的是key。

间隙锁（Gap Lock）:锁定索引记录间隙，确保索引记录的间隙不变。间隙锁是针对事务隔离级别为可重复读或以上级别。

Next-Key Lock ：行锁和间隙锁组合起来就叫Next-Key Lock。

默认情况下，InnoDB工作在可重复读隔离级别下，并且会以Next-Key Lock的方式对数据行进行加锁，这样可以有效防止幻读的发生。Next-Key Lock是行锁和间隙锁的组合，当InnoDB扫描索引记录的时候，会首先对索引记录加上行锁（Record Lock），再对索引记录两边的间隙加上间隙锁（Gap Lock）。加上间隙锁之后，其他事务就不能在这个间隙修改或者插入记录。

## 二、数据库死锁定义及其产生的必要条件 ##

所谓数据库死锁是指两个或多个事务，各自占有对方的期望获得的资源，形成的循环等待，彼此无法继续正常执行的一种状态。

从业务层看死锁产生具有一定的概率性，当具备了以下几个必要条件时，则会出现死锁：

*  互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用完释放。
 *  请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己获得的其它资源保持不放。
 *  不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
 *  环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合\{P0，P1，P2，···，Pn\}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。

[Multi-Version Concurrency Control]: http://en.wikipedia.org/wiki/Multiversion_concurrency_control