InnoDB锁

野性酷女 2021-11-14 12:28 276阅读 0赞

## InnoDB锁 ##

锁是数据库系统区别于文件系统的一个关键特性, 锁机制用于\*\*管理对共享资源的并发访问.\*\*InnoDB存储引擎会在行级别上对表数据上锁, 也会在数据库其他地方使用锁, 从而允许对多种不同资源提供并发访问. 例如, LRU列表, 删除, 添加, 移动LRU列表中的元素, 为了保证一致性, 必须有锁的介入. 数据库系统使用锁是为了支持对共享资源进行并发访问, 提供数据的完整性和一致性

### 1.lock与latch ###

*  latch一般称为闩锁(轻量级的锁), 因为其要求锁定的时间非常短. InnoDB中, latch又可以分为mutex(互斥量)和rwlock(读写锁). 其目的是用来保证并发线程操作临界资源的正确性, 并且通常没有死锁检测的机制
 *  lock的对象是事务, 用来锁定的是数据库中的对象, 如 表, 页, 行. 并且一般lock的对象仅在事务 commit或rollback后进行释放

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>lock</th> 
   <th>latch</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>对象</td> 
   <td>事务</td> 
   <td>线程</td> 
  </tr> 
  <tr> 
   <td>保护</td> 
   <td>数据库内容</td> 
   <td>内存数据结构</td> 
  </tr> 
  <tr> 
   <td>持续时间</td> 
   <td>整个事务过程</td> 
   <td>临界资源</td> 
  </tr> 
  <tr> 
   <td>模式</td> 
   <td>行锁, 表锁, 意向锁</td> 
   <td>读写锁, 互斥锁</td> 
  </tr> 
  <tr> 
   <td>死锁</td> 
   <td>通过wait-for graph, time out等机制进行死锁检测和处理</td> 
   <td>无私所检测与处理,仅通过应用程序加锁的顺序(lock leveling)保证无死锁的情况发生</td> 
  </tr> 
  <tr> 
   <td>存在于</td> 
   <td>Lock Manager的哈希表中</td> 
   <td>每个数据结构的对象中</td> 
  </tr> 
 </tbody> 
</table>

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

#### 1>锁的类型 ####

InnoDB实现了如下两种标准的行级锁

*  共享锁(S Lock) : 允许事务读一行
 *  排他锁(X Lock) : 允许事务删除或更新一行数据

X锁与任何 的锁都不兼容, , 仅S锁和S锁兼容, S锁和X锁都是行锁, 兼容是指对同一记录(row)锁的兼容性情况

此外, InnoDB支持多粒度锁定, 这种锁定允许事务在行级上的锁和标记上的锁同时存在. 为了支持在不同粒度 上进行加锁操作, InnoDB支持一种额外的锁方式, 称为意向锁. **意向锁是将锁定的对象分为 多个层次, 意向锁意味着事务希望在更细粒度上进行加锁**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dpbnRlcnNoaWk_size_16_color_FFFFFF_t_70]

若将上锁的对象看成一棵树, 那么对最下层的对象上锁, 也就是对最细粒度的对象进行上锁, 那么首先需要对粗粒度的对象上锁.如图, 如果需要给页上的记录r进行上X锁, 那么分别需要对数据库A, 表, 页上意向锁IX, 最后对记录r上X锁. 若其中任何一个部分导致等待, 那么该操作需要等待粗粒度的完成

InnoDB支持意向锁的设计比较简单, 其意向锁即为表级别的锁. 设计目的主要是为了在下一个事务中揭示下一行 将被请求的锁类型. 其中支持两种意向锁 :

*  意向共享锁(IS Lock), 事务想要获得一张表中某几行的共享锁
 *  意向排他锁(IX Lock), 事务想要获得一张表中某几行的排他锁

由于InnoDB存储引擎支持的是行级别的表, 因此意向锁其实不会阻塞除全表以外的任何请求

#### 2>一致性非锁定读 ####

一致性的非锁定读是指 InnoDB通过多版本控制的方式来读取当前执行时间数据库中行的数据. 如果读取的行正在进行DELETE或UPDATE操作, 这时读取操作不会因此等待行上锁的释放. 相反地, InnoDB存储引擎会去读取行的一个**快照数据.**

之所以称为非锁定读, 因为不需要等待访问的行上X锁的释放. 快照数据是指该行之前版本的数据, 该实现是通过undo段来完成. 而undo段用在事务中回滚数据, 因此快照数据本身没有额外的开销. 此外, 读取快照数据是不需要上锁的, 因为没有实物需要对历史的数据进行修改操作

非锁定读打打提高了数据库的并发性, 在InnoDB默认设置下, 这是默认的读取方式, 即读取不会占用和等待表上的锁, 但在不同的事务隔离级别下, 读取的方式不同, 并不是在每个事务隔离级别下都是采用非锁定的一致性读. 此外, 及时都是使用非锁定的一致性读, 但对于快照数据的定义也各不相同.

快照数据其实就是当前数据之前的历史版本, 每行记录可能有多个版本, 一般称这种技术为行多版本技术 , 由此带来的并发控制称为多版本并发控制(MVCC)

在事务隔离级别 READ COMMITED和REPEATABLE READ下, InnoDB使用非锁定的一致性读, 但对快照数据的定义却不相同. 在READ COMMITED事务隔离级别下, 对于快照数据, 非一致性读总是读取被锁定行的**最新一份快照数据**. 而在REPEATABLE READ事务隔离级别下, 对于快照数据, 非一致性读总是读取**事务开始时的行数据版本**

实际上, 对于READ COMMITED的事务隔离级别而言, 从数据库理论的角度看, 其违反了事务ACID中的I特性, 即隔离性

#### 3>一致性锁定读 ####

在默认配置下, 即事务的隔离级别为REPEATEBLE READ模式下, InnoDB的 SELECT操作使用一致性非锁定读. 但是在某些情况下, 用户需要显式地对数据库读取操作进行加锁以保证数据逻辑的一致性.而这要求数据库支持加锁语句, 即使对于SELECT的只读操作, InnoDB对于SELECT语句支持两种**一致性的锁定读**操作

*  SELECT … FOR UPDATE
 *  SELECT … LOCK INSHARE MODE

SELECT … FOR UPDATE对读取的行记录加一个X锁, 其他事物不能对已锁定的行加上任何锁

SELECT … LOCK IN SHARE MODE对读取的行加上一个S锁, 其他事务可以向被锁定的行加S锁, 但是如果加X锁, 则会被阻塞

#### 4>自增长与锁 ####

自增长在数据库中是非常常见的一种属性, 也是很多人首选的主键方式. 在InnoDB的内存结构中, 对每个含有自增长值的表都有一个自增长计数器. 插入操作会依据这个自增长的计数器值加1赋予自增长列. 这个实现方式称作AUTO-INC Locking. 这种锁其实是采用一种特殊的表锁机制, 为了提高插入的性能, 锁不是在一个事务完成后才释放, 而是完成自增长值插入的SQL语句后立即释放

从MySQL 5.1.22开始, InnoDB提供了一种轻量级**互斥量的自增长实现机制, 大大提高了自增长值插入的性能**

在InnoDB中, 自增长的列必须是索引, 同时必须是索引的第一个列, 如果不是第一个列 则会抛出异常

#### 5>外键和锁 ####

外键主要用于引用完整性的约束检查, InnoDB中会自动对一个外键列加索引, 因为这样可以避免表锁

对于外键值的插入或更新, 首先需要查询父表中的记录, 即SELECT父表, 但是对于父表的SELECT操作, 不是使用一致性非锁定读的方式, 因为这样会发生数据不一致的问题. 这时使用的是SELECT … LOCK IN SHARE MODE方式, 即主动对父表加一个S锁. 如果此时父表已经上了X锁, 字表上的操作会被阻塞

### 3.锁的算法 ###

#### 1> 锁的三种算法 ####

InnoDB存储引擎有3种行锁的算法, 其分别是

*  Record Lock : 单个行记录上的锁
 *  Gap Lock : 间隙锁, 锁定一个范围, 但不包含记录本身
 *  Next-Key Lock : Gap Lock+Record Lock, 锁定一个范围, 并且锁定记录本身

Record Lock总是回去锁住索引记录, 如果InnoDB存储引擎在建立的时候没有设置任何一个索引, 那么这时InnoDB会使用隐式的主键来进行锁定

Next-Key Lock 是结合了Gap Lock和Record Lock的一种锁定算法, 在Next-Key算发现, InnoDB对于行的查询都是采用这种锁定算法. 但当查询的索引含有唯一属性时, InnoDB存储引擎会对Next-Key Lock进行优化, 将其降级为Record Lock, 仅锁住记录本身, 而不是范围.但Next-Key Lock降级为Record Lock仅在查询的列是唯一索引的情况下. 若是辅助索引, 则情况会完全不同.

CREATE TABLE z (a INT , b INT , PRIMARY KEY(a), KEY(b) );
    INSERT INTO z SELECT 1,1;
    INSERT INTO z SELECT 3,1;
    INSERT INTO z SELECT 5,3;
    INSERT INTO z SELECT 7,6;
    INSERT INTO z SELECT 10,8;

表z的列b是辅助索引, 如此时执行这样一句SQL语句 : SELECT \* FROM z WHERE b = 3 FOR UPDATE

很明显, 这时SQL语句通过索引列b进行查询, 因此其使用传统的Next-Key Locking技术加锁, 由于有两个索引, 需要对其分别锁定. 对于聚集索引, 其仅对列a等于5的索引加上Record Lock. 而对于辅助索引, 其加上的是Next-Key Lock, 锁定的范围是(1,3), 另外, InnoDB还会对辅助索引下一个键值加上gap lock, 即还有一个索引范围为(3,6)的锁.

Gap Lock的作用是为了阻止多个事务将记录插入到同一范围内, 而这会导致**幻读**问题的产生

最后需要再次提醒的是,对于唯一键值的锁定, Next-Key Lock降级为Record Lock仅存在于查询所有的唯一索引列. 若唯一索引列由多个列组成, 而查询仅是查找多个唯一索引列中的一个, 那么查询其实是range查询, 而不是point类型查询, 故InnoDB采用Next-Key Lock进行锁定

#### 2>解决幻读问题 ####

在默认的事务隔离级别下, 即REPETABLE READ下, InnoDB存储引擎采用Next-Key Locking机制来避免幻读问题.

幻读问题是指在同一事务下, **连续执行两次同样的SQL语句, 可能导致不同的结果, 第二次的SQL语句可能会返回之前不存在的行**

此外, 用户可以通过InnoDB存储引擎的Next-Key Locking机制在应用层面实现唯一性的检查.

如果用户通过索引查询一个值, 并对该行加上一个SLock, 那么即使查询的值不在, 其锁定的也是一个范围, 因此若没有返回任何行, 那么新插入的值一定是唯一的.

### 4.锁问题 ###

#### 1>脏读 ####

*  脏页 : 指的是在缓冲池中已经被修改的页, 但是还没刷新到磁盘中, 即数据库实例内存中的页和磁盘中的页的数据是不一致的. 当然在刷新到磁盘之前, 日志都已经被写入到了重做日志文件中.
 *  脏数据是指事务对缓冲池中行记录的修改, 并且还没有提交

对于脏页的读取, 是非常正常的. 脏页是因为数据库实例内存和磁盘的异步造成的, 这并不影响数据的一致性(或者说两者最终会达到一致性, 即脏页都刷回到磁盘). 并且因为脏页的刷新是异步的, 不影响数据库的可用性, 因此可以带来性能的提高

脏数据是指未提交的数据, 如果读到了脏数据, 即**一个事务可以读到另外一个事务中未提交的数据**, 则显然违背了数据库的隔离性

脏读发生的条件是需要事务的隔离级别为READ UNCOMMITED, 而目前大部分的数据库都至少设置成READ COMMITED. InnoDB存储引擎默认的事务隔离级别为READ REPEATABLE.

#### 2>不可重复读 ####

不可重复读是指在一个事务内多次读取同一数据集合. 在这个事务还没有结束时, 另外一个事务页访问该同一集合, 并做了一些DML操作. 因此, 在第一个事务中的两次读数据之间, 由于第二个事务的修改, 那么第一个事务两次读到的数据可能是不一样的. 这样就发生了在一个事务内两次独到的数据是不一样的情况, 这种情况称为不可重复读

一般来说, 不可重复读的问题是可以接受的, 因为其独到的是已经提交的数据, 本身不会带来很大的问题

在InnoDB中, 通过使用Next-Key Lock算法来避免不可重复读的问题. 在MySQL官方文档中将不可重复读定义为幻读问题. 在Next-Key Lock算法下, 对于索引的扫描, 不仅是锁住扫描到的索引, 还锁住这些索引覆盖的范围. 因此在这个范围内的插入都是不允许的, 这样就避免了另外的事务在这个范围内插入数据而导致的不可冲嘟嘟的问题. 因此InnoDB默认事务隔离级别是READ REPEATABLE, 采用Next-Key Lock算法, 避免了不可重复读的现象

#### 3>丢失更新 ####

丢失更新是另一个锁导致的问题, 简单来说就是一个事务的更新操作会被另一个事务的更新操作所覆盖, 从而导致数据的不一致

简单来说, 出现下面的情况, 就会发生丢失更新

*  1.事务T1查询一行数据, 放入本地内存, 并显示给一个终端用户User1
 *  2.事务T2页查询该行数据, 并将取得的数据显示给终端用户User2
 *  3.User1修改这行记录, 更新数据库并提交
 *  4.User2修改这行记录, 更新数据库并提交

显然, 这个时候用户User1的修改更新操作丢失了, 这在例如银行转账系统的情况下是很危险的

要避免丢失更新的发生, 需要让食物在这种情况下的操作变成串行化, 而不是并行操作

### 5.阻塞 ###

因为不同锁之间的兼容性关系, 在有些时刻一个事务中的锁需要等待另一个事务中的锁释放它所占用的资源, 这就是阻塞. 阻塞并不是一件坏事, 是为了确保事务可以并发且正常地运行

在默认情况下, InnoDB不会回滚超时引发的错误异常.其实InnoDB在大部分情况下都不会对异常进行回滚, 事务虽然抛出了异常, 但是既没有进行COMMIT操作, 也没有进行ROLLBACK, 这是时分危险的状态, 所以用户必须判断是否需要COMMIT还是ROLLBACK, 之后再进行下一步的操作

### 6.死锁 ###

#### 1>死锁概念 ####

**死锁是指两个或两个以上的事务在执行过程中, 因争夺锁资源而造成的一种互相等待的现象.** 若无外力作用, 事务都将无法进行下去. 解决死锁问题最简单的方式是不要有等待, 将任何的等待都转化为回滚, 并且事务重新开始, 但是这将造成并发性能的下降, 甚至任何一个事务都不能进行

解决死锁最简单的一种方式是超时, 即当两个事务互相等待时, 当一个等待时间超过设置的某一阀值时, 其中一个事务进行回滚, 另一个等待的事务就能继续运行.

超时机制虽然简单, 但是仅通过超时后对事务进行回滚的方式来处理, 或者说是根据FIFO的顺序选择回滚对象. 但若超时的事务所占权重比较大, 如事务操作更新了很多行, 占用了较多的undo log, 这时采用FIFO方式, 就显得不合适了, 回滚这个事务的时间相对另一个事务所占用的时间可能会很多

因此除了超时机制, 当前数据库还都普遍采用wait-for graph(等待图)的方式来进行死锁检测. 较之超市的解决方案, 这是一种更为主动的死锁检测方式.

wait-for graph要求数据库保存以下两种信息 :

*  锁的信息链表
 *  事务等待链表

通过上述链表可以构造出一张图, 而在这个图中若存在回路, 就代表存在死锁. 在每个事务请求锁并发生等待时都会判断是否存在回路, 若存在则有死锁, InnoDB会选择回滚undo量最小的事务

### 7.锁升级 ###

锁升级是指将当前锁的粒度降低, 距离来说, 数据库可以把一个表的1000个行锁升级为一个页锁, 或者将页锁升级为表锁. 如果数据库的设计中认为锁一种稀有资源, 并且想避免锁的开销, 那数据库就会频繁出现升级现象.这种升级保护了系统资源, 防止系统用太多的内存来维护锁, 在一定程度上提高了效率

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dpbnRlcnNoaWk_size_16_color_FFFFFF_t_70]: /images/20211114/79378f29737947f3af95f5caa0c6a0cd.png