mysql 学习---InnoDB 锁机制解析 Next-Key Locks

     InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。这里就着重介绍下它的锁机制。

   锁是用于管理不同事务对共享资源的并发访问。

一、InnoDB锁类型

1.1、 InnoDB锁基本类型：

 1、共享锁（行锁）：Shared Locks 又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改;

 2、排它锁（行锁）：Exclusive Locks  又称为写锁，简称X锁，排他锁不能与其他锁并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的锁（共享锁、排他锁），只有该获取了排他锁的事务是可以对数据行进行读取和修改，（其他事务要读取数据可来自于快照） 

3、意向锁共享锁（表锁）：Intention Shared Locks 表示事务准备给数据行加入共享锁，即一个数据行加共享锁前必须先取得该表的IS锁，意向共享锁之间是可以相互兼容的。

4、意向锁排它锁（表锁）：Intention Exclusive Locks 表示事务准备给数据行加入排他锁，即一个数据行加排他锁前必须先取得该表的IX锁，意向排它锁之间是可以相互兼容的

5、自增锁：AUTO-INC Locks  针对自增列自增长的一个特殊的表级别锁，show variables like 'innodb_autoinc_lock_mode';默认取值1，代表连续，事务未提交ID永久丢失

1.2 、锁的算法：

 1、 临键锁 Next-key Locks：Gap Lock+Record Lock，锁定一个范围，并且锁定记录本身。

 2、记录锁 Record Locks：单个记录上的锁，当sql执行按照唯一性（Primary key、Unique key）索引进行数据的检索时，查询条件等值匹配且查询的数据是存在，这时SQL语句加上的锁即为记录锁Record locks，锁住具体的索引项。

3、间隙锁 Gap Locks：锁住数据不存在的区间（左开右开）当sql执行按照索引进行数据的检索时，查询条件的数据不存在，这时SQL语句加上的锁即为Gap locks，锁住索引不存在的区间（左开右开）。

二、锁的详情

2.1、共享锁与排他锁

InnoDB默认使用行锁，实现了两种标准的行锁——共享锁与排他锁；

2.1.1、共享锁:

    又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁， 都能访问到数据，但是只能读不能修改;
   加锁释锁方式：

           select * from users WHERE id=1 LOCK IN SHARE MODE; commit/rollback

2.1.2、排他锁:

   又称为写锁，简称X锁，排他锁不能与其他锁并存，如一个事务获取了一个数据行的排他 锁，其他事务就不能再获取该行的锁（共享锁、排他锁），只有该获取了排他锁的事务是可以对 数据行进行读取和修改，（其他事务要读取数据可来自于快照）

 加锁释锁方式：

            delete / update / insert 默认加上X锁

             SELECT * FROM table_name WHERE ... FOR UPDATE

              commit/rollback

      另外还需要注意的是：InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！

2.2 、意向锁(Intention Locks)

      InnoDB为了支持多粒度锁机制(multiple granularity locking)，即允许行级锁与表级锁共存，而引入了意向锁(intention locks)。意向锁是指，未来的某个时刻，事务可能要加共享/排它锁了，先提前声明一个意向。

意向锁是一个表级别的锁(table-level locking)；

意向锁又分为：

• 意向共享锁(intention shared lock, IS)，它预示着，事务有意向对表中的某些行加共享S锁；

• 意向排它锁(intention exclusive lock, IX)，它预示着，事务有意向对表中的某些行加排它X锁；

意义：当事务想去进行锁表时，可以先判断意向锁是否存在，存在时则可快速返回该表不能 启用表锁。

2.3、自增锁：AUTO-INC Locks

    自增锁：AUTO-INC Locks  针对自增列自增长的一个特殊的表级别锁，show variables like 'innodb_autoinc_lock_mode';默认取值1，代表连续，事务未提交ID永久丢失

三、锁的算法

从实现算法上来分的话，Innodb的三种行锁分别是：间隙锁、记录锁和临键锁

、

InnoDB所有的行锁算法都是基于索引实现的，锁定的也都是索引或索引区间；

    不同的事务隔离级别、不同的索引类型、是否为等值查询，使用的行锁算法也会有所不同；下面仅以InnoDB默认的RR隔离级别、等值查询为例，介绍几种行锁算法：

3.1、间隙锁(Gap Locks)

锁住数据不存在的区间（左开右开）

当sql执行按照索引进行数据的检索时，查询条件的数据不存在，这时SQL语句加上的锁即为 Gap locks，锁住索引不存在的区间（左开右开）

间隙锁的目的

• 防止幻读,以满足相关隔离级别的要求

对于上例,若不使用间隙锁,如果其他事务插入 id大于 100 的任何记录,那么本事务如果再次执行上述语句,就会发生幻读。

• 满足其恢复和复制的需要

在使用范围条件检索并锁定记录时，InnoDB 这种加锁机制会阻塞符合条件范围内键值的并发插入,这往往会造成严重的锁等待，因此,在实际开发中,尤其是并发插入较多的应用，我们要尽量优化业务逻辑,尽量使用相等条件来访问更新数据,避免使用范围条件。

3.2、记录锁(Record Locks)

当查询的条件为 主键索引 或者 为唯一索引 会使用 Record Locks。

如下图所示：

需要注意的是： 列必须为唯一索引列或主键列，否则上述语句加的锁就会变成临键锁。

同时查询语句必须为精准匹配（=），不能为 >、<、like等，否则也会退化成临键锁。

3.3、临键锁（Next-Key Locks）

 临键锁 Next-Key Lock：通过Gap Lock+Record Lock 实现，锁定一个范围，并且锁定记录本身， 是InnoDB默认的行锁算法。

示例如下：

       Next-Key 可以理解为一种特殊的间隙锁，也可以理解为一种特殊的算法。通过临键锁可以解决幻读的问题。 每个数据行上的非唯一索引列上都会存在一把临键锁，当某个事务持有该数据行的临键锁时，会锁住一段左开右闭区间的数据。需要强调的一点是，InnoDB 中行级锁是基于索引实现的，临键锁只与非唯一索引列有关，在唯一索引列（包括主键列）上不存在临键锁,会降级为记录锁，即仅锁住索引本身，不是范围。

四、快照读和当前读

    快照读：SQL读取的数据是快照版本，也就是历史版本，普通的SELECT就是快照读innodb快照读，数据的读取将由 cache(原本数据) + undo(事务修改过的数据) 两部分组成。

   当前读：SQL读取的数据是最新版本。通过锁机制来保证读取的数据无法通过其他事务进行修改UPDATE、DELETE、INSERT、SELECT …  LOCK IN SHARE MODE、SELECT … FOR UPDATE都是当前读

五、死锁和死锁检测

     当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。这里我用数据库中的行锁举个例子。

  

这时候，事务 A 在等待事务 B 释放 id=2 的行锁，而事务 B 在等待事务 A 释放 id=1 的行锁。 事务 A 和事务 B 在互相等待对方的资源释放，就是进入了死锁状态。当出现死锁以后，有两种策略：

• 一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。
• 另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

在 InnoDB 中，innodb_lock_wait_timeout 的默认值是 50s，意味着如果采用第一个策略，当出现死锁以后，第一个被锁住的线程要过 50s 才会超时退出，然后其他线程才有可能继续执行。对于在线服务来说，这个等待时间往往是无法接受的。

但是，我们又不可能直接把这个时间设置成一个很小的值，比如 1s。这样当出现死锁的时候，确实很快就可以解开，但如果不是死锁，而是简单的锁等待呢？所以，超时时间设置太短的话，会出现很多误伤。

所以，正常情况下我们还是要采用第二种策略，即：主动死锁检测，而且 innodb_deadlock_detect 的默认值本身就是 on。主动死锁检测在发生死锁的时候，是能够快速发现并进行处理的，但是它也是有额外负担的。

你可以想象一下这个过程：每当一个事务被锁的时候，就要看看它所依赖的线程有没有被别人锁住，如此循环，最后判断是否出现了循环等待，也就是死锁。

那如果是我们上面说到的所有事务都要更新同一行的场景呢？

每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是 O(n) 的操作。假设有 1000 个并发线程要同时更新同一行，那么死锁检测操作就是 100 万这个量级的。虽然最终检测的结果是没有死锁，但是这期间要消耗大量的 CPU 资源。因此，你就会看到 CPU 利用率很高，但是每秒却执行不了几个事务。

根据上面的分析，我们来讨论一下，怎么解决由这种热点行更新导致的性能问题呢？问题的症结在于，死锁检测要耗费大量的 CPU 资源。

一种头痛医头的方法，就是如果你能确保这个业务一定不会出现死锁，可以临时把死锁检测关掉。但是这种操作本身带有一定的风险，因为业务设计的时候一般不会把死锁当做一个严重错误，毕竟出现死锁了，就回滚，然后通过业务重试一般就没问题了，这是业务无损的。而关掉死锁检测意味着可能会出现大量的超时，这是业务有损的。

另一个思路是控制并发度。根据上面的分析，你会发现如果并发能够控制住，比如同一行同时最多只有 10 个线程在更新，那么死锁检测的成本很低，就不会出现这个问题。一个直接的想法就是，在客户端做并发控制。但是，你会很快发现这个方法不太可行，因为客户端很多。我见过一个应用，有 600 个客户端，这样即使每个客户端控制到只有 5 个并发线程，汇总到数据库服务端以后，峰值并发数也可能要达到 3000。

因此，这个并发控制要做在数据库服务端。如果你有中间件，可以考虑在中间件实现；如果你的团队有能修改 MySQL 源码的人，也可以做在 MySQL 里面。基本思路就是，对于相同行的更新，在进入引擎之前排队。这样在 InnoDB 内部就不会有大量的死锁检测工作了。

可能你会问，如果团队里暂时没有数据库方面的专家，不能实现这样的方案，能不能从设计上优化这个问题呢？

你可以考虑通过将一行改成逻辑上的多行来减少锁冲突。还是以影院账户为例，可以考虑放在多条记录上，比如 10 个记录，影院的账户总额等于这 10 个记录的值的总和。这样每次要给影院账户加金额的时候，随机选其中一条记录来加。这样每次冲突概率变成原来的 1/10，可以减少锁等待个数，也就减少了死锁检测的 CPU 消耗。

这个方案看上去是无损的，但其实这类方案需要根据业务逻辑做详细设计。如果账户余额可能会减少，比如退票逻辑，那么这时候就需要考虑当一部分行记录变成 0 的时候，代码要有特殊处理。

下面是一个死锁排除的案例：https://mp.weixin.qq.com/s/II-rDjXRDnR2jzxbXI_3zg

总结

MySQL 的 Innodb引擎正是通过上述不同类型的锁，完成了事务隔离：

• 加 X 锁 避免了数据的脏读

• 加 S 锁 避免了数据的不可重复读

• 加上 Next Key 避免了数据的幻读