深入MySQL底层3-事务与锁机制

1.事务

1.1 事务基础概念

事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败。
默认MySQL的事务是自动提交的，也就是说，当执行完一条DML语句时，MySQL会立即隐式的提交事务。

1.2 事务基础操作

事务操作一：
1). 查看/设置事务提交方式

SELECT @@autocommit ;
SET @@autocommit = 0 ;

2). 提交事务

COMMIT;

3). 回滚事务

ROLLBACK;

上述的这种方式，我们是修改了事务的自动提交行为, 把默认的自动提交修改为了手动提
交, 此时我们执行的DML语句都不会提交, 需要手动的执行commit进行提交。
事务操作二：
1). 开启事务

START TRANSACTION 或 BEGIN;

2). 提交事务

COMMIT;

3). 回滚事务

ROLLBACK;

转账案例：

-- 开启事务
start transaction
-- 1. 查询张三余额
select * from account where name = '张三';
-- 2. 张三的余额减少1000
update account set money = money - 1000 where name = '张三';
-- 3. 李四的余额增加1000
update account set money = money + 1000 where name = '李四';
-- 如果正常执行完毕, 则提交事务
commit;
-- 如果执行过程中报错, 则回滚事务
-- rollback;

1.3 事务四大特性

原子性（Atomicity **）：**事务是不可分割的最小操作单元，要么全部成功，要么全部失败。
一致性（Consistency **）：**事务完成时，必须使所有的数据都保持一致状态。
隔离性（Isolation **）：**数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立
环境下运行。
持久性（Durability **）：**事务一旦提交或回滚，它对数据库中的数据的改变就是永久的。
而对于这四大特性，实际上分为两个部分。 其中的原子性、一致性、持久化，实际上是由InnoDB中的两份日志来保证的，一份是redo log日志，一份是undo log日志。 而持久性是通过数据库的锁，加上MVCC来保证的。

1.4 并发事务问题

1). 赃读：
一个事务读到另外一个事务还没有提交的数据。
举例：假设AB两个事务同时在处理，事务A先从数据库中读取某人余额数据，然后执行更新操作，如果此时A还未提交事务，正好此时B也从数据库中读取这个余额数据，那么此时B读取到的是修改后的数据，即使此时A还未提交事务

2). 不可重复读：
一个事务先后读取同一条记录，但两次读取的数据不同，称之为不可重复读。
举例：A读取数据，B更新数据，A再读取数据，两个读取不同

3). 幻读：
一个事务按照条件查询数据时，没有对应的数据行，但是在插入数据时，又发现这行数据已经存在，好像出现了 "幻影"。
举例：A和B两个事务同时处理，A先从数据库中查询余额大于100的用户记录，发现有5条，然后B进行同样的搜索，也是5条，接下来，A又插入一条余额大于100的数据，此时B再查询发现是6条

1.5 事务隔离级别

为了解决并发事务所引发的问题，在数据库中引入了事务隔离级别。主要有以下几种：

**1.读未提交：**一个事务还未提交，它的变更就能被其他事务看到

read uncommit 会引发三种并发问题

**2.读提交：**一个事务提交后，它的变更才能被其他事务看到

read commit 会引发不可重复读和幻读

**3.可重复读：**一个事务执行过程中看到数据，一直跟这个事务启动时看到的数据是一致的

repeatable read(默认):会引发幻读

**4.串行化：**会对记录加上读写锁，再多个事务对这条记录进行读写操作时，如果发生了读写冲突，后访问的事务必须等前一个事务执行完，才能继续执行

serivale:不会引发并发事务问题
1). 查看事务隔离级别

SELECT @@TRANSACTION_ISOLATION;

2). 设置事务隔离级别

SET [ SESSION | GLOBAL ] TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED |
READ COMMITTED | REPEATABLE READ | SERIALIZABLE }

事务隔离级别越高，数据越安全，但是性能越低。
实例说明：
有一张余额表，里面有一条余额为100W的数据，有两个并发事务AB，A负责查询余额，B会把余额改为200W

**读未提交：**事务B修改余额后，虽然未提交事务，但是此时余额可以被A看见

**读提交：**事务B修改余额后，因为没有提交事务，A查询余额还是100W，等B提交完，A才能查出200W

**可重复读：**A只能看到启动事务时查到的100W，当A提交事务时才能查到200W

**串行化：**B将100W改为200W，由于此前A执行了读操作，就发生了读写冲突，会加读写锁操作，A提交后，B才能正确执行

哪些场景不适合脏读：

银行系统一个用户的账户正在被调整但尚未提交，另一个事务读取到这个临时余额，可能导致客户看不到准确信息。

在线订单系统订单修改尚未提交被另一个事务读取到订单状态导致用户收到不准确信息。

2. redolog & undolog

2.1 redolog

重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性。
该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log file）,前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中, 用于在刷新脏页到磁盘,发生错误时, 进行数据恢复使用。
如果没有redolog，可能会存在什么问题的？ 我们一起来分析一下。
我们知道，在InnoDB引擎中的内存结构中，主要的内存区域就是缓冲池，在缓冲池中缓存了很多的数据页。 当我们在一个事务中，执行多个增删改的操作时，InnoDB引擎会先操作缓冲池中的数据，如果缓冲区没有对应的数据，会通过后台线程将磁盘中的数据加载出来，存放在缓冲区中，然后将缓冲池中的数据修改，修改后的数据页我们称为脏页。 而脏页则会在一定的时机，通过后台线程刷新到磁盘中，从而保证缓冲区与磁盘的数据一致。 而缓冲区的脏页数据并不是实时刷新的，而是一段时间之后将缓冲区的数据刷新到磁盘中，假如刷新到磁盘的过程出错了，而提示给用户事务提交成功，而数据却没有持久化下来，这就出现问题了，没有保证事务的持久性。

那么，如何解决上述的问题呢？ 在InnoDB中提供了一份日志 redo log，接下来我们再来分析一
下，通过redolog如何解决这个问题。

有了redolog之后，当对缓冲区的数据进行增删改之后，会首先将操作的数据页的变化，记录在redolog buffer中。在事务提交时，会将redo log buffer中的数据刷新到redo log磁盘文件中。
过一段时间之后，如果刷新缓冲区的脏页到磁盘时，发生错误，此时就可以借助于redo log进行数据恢复，这样就保证了事务的持久性。 而如果脏页成功刷新到磁盘或或者涉及到的数据已经盘，此时redolog就没有作用了，就可以删除了，所以存在的两个redolog文件是循环写的。
那为什么每一次提交事务，要刷新redo log 到磁盘中呢，而不是直接将buffer pool中的脏页刷新到磁盘呢 ?
因为在业务操作中，我们操作数据一般都是随机读写磁盘的，而不是顺序读写磁盘。 而redo log在
往磁盘文件中写入数据，由于是日志文件，所以都是顺序写的。顺序写的效率，要远大于随机写。 这种先写日志的方式，称之为 WAL（Write-Ahead Logging）。

2.2 undolog

回滚日志，用于记录数据被修改前的信息 , 作用包含两个 : 提供回滚(保证事务的原子性) 和
MVCC(多版本并发控制) 。
undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo
log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的
update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
Undo log销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些
日志可能还用于MVCC。
Undo log存储：undo log采用段的方式进行管理和记录，存放在前面介绍的 rollback segment
回滚段中，内部包含1024个undo log segment。

3.MVCC

3.1 基础概念

1). 当前读
读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select ... lock in share mode(共享锁)，select ... for update、update、insert、delete(排他锁)都是一种当前读。
在默认的RR隔离级别下，在查询语句后面加上了 lock in share mode 共享锁，事务A中依然可以读取到事务B最新提交的内容，此时是当前读操作。当然，当我们加排他锁的时候，也是当前读操作。
2). 快照读
简单的select（不加锁）就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据， 不加锁，是非阻塞读。
• Read Committed：每次select，都生成一个快照读。
• Repeatable Read：开启事务后第一个select语句才是快照读的地方。
• Serializable：快照读会退化为当前读。
3). MVCC
全称 Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。

3.2 三个隐藏字段

当我们创建了一张表，我们在查看表结构的时候，就可以显式的看到我们创建的表结构字段。 实际上除了我们创建的表结构字段以外，InnoDB还会自动的给我们添加三个隐藏字段：

而上述的前两个字段是肯定会添加的， 是否添加最后一个字段DB_ROW_ID，得看当前表有没有主键， 如果有主键，则不会添加该隐藏字段。

3.3 undolog

回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志。
当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。
而update、delete的时候，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即
被删除。
版本链：
有一张表原始数据为：
DB_TRX_ID : 代表最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID，是自增的。
DB_ROLL_PTR ： 由于这条数据是才插入的，没有被更新过，所以该字段值为null。
然后，有四个并发事务同时在访问这张表。
A. 第一步

当事务2执行第一条修改语句时，会记录undo log日志，记录数据变更之前的样子; 然后更新记录，
并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。
B.第二步

当事务3执行第一条修改语句时，也会记录undo log日志，记录数据变更之前的样子; 然后更新记
录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。

C. 第三步

当事务4执行第一条修改语句时，也会记录undo log日志，记录数据变更之前的样子; 然后更新记
录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。
最终我们发现，不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条
记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧记录。

3.4 readview

ReadView（读视图）是快照读 SQL执行时MVCC提取数据的依据，决定快照读SQL执行时MVCC提取哪一条数据 ，记录并维护系统当前活跃的事务（未提交的）id。
ReadView中包含了四个核心字段:
而在readview中就规定了版本链数据的访问规则：
trx_id 代表当前undolog版本链对应事务ID。

undolog版本链对应的事务id==创建者事务id 则可以访问该版本，数据是当前事务更改的

undolog版本链对应的事务id<最小活跃事务id,则可以访问该版本，数据已经提交

undolog版本链对应的事务id>预分配事务id,则不可以访问该版本，事务在Readview生成后才开启

最小活跃事务id<=undolog版本链对应的事务id<=预分配事务id:如果当前undolog版本链对应的事务id不在活跃事务id集合中，则可以访问，说明数据已经提交
不同的隔离级别，生成ReadView的时机不同：
READ COMMITTED ：在事务中每一次执行快照读时生成ReadView。
REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。

3.5 原理分析

3.5.1 RC隔离级别

RC隔离级别下，在事务中每一次执行快照读时生成ReadView。
我们就来分析事务5中，两次快照读读取数据，是如何获取数据的?
在事务5中，查询了两次id为30的记录，由于隔离级别为Read Committed，所以每一次进行快照读
都会生成一个ReadView，那么两次生成的ReadView如下。
那么这两次快照读在获取数据时，就需要根据所生成的ReadView以及ReadView的版本链访问规则， 到undolog版本链中匹配数据，最终决定此次快照读返回的数据。
A. 先来看第一次快照读具体的读取过程：

B. 再来看第二次快照读具体的读取过程:

3.5.2 RR隔离级别

RR隔离级别下，仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。 而RR 是可重复读，在一个事务中，执行两次相同的select语句，查询到的结果是一样的。

我们看到，在RR隔离级别下，只是在事务中第一次快照读时生成ReadView，后续都是复用该
ReadView，那么既然ReadView都一样， ReadView的版本链匹配规则也一样， 那么最终快照读返回的结果也是一样的。
所以，MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。 而MVCC + 锁，则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证。

4.锁机制

锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源（CPU、 RAM、I/O）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。
MySQL中的锁，按照锁的粒度分，分为以下三类：
**全局锁：**锁定数据库中的所有表。
表级锁：每次操作锁住整张表。
**行级锁：**每次操作锁住对应的行数据。

4.1 全局锁

4.1.1 介绍

全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，已经更新操作的事务提交语句都将被阻塞。其典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性。
为什么全库逻辑备份，就需要加全局锁呢？
A. 我们一起先来分析一下不加全局锁，可能存在的问题。
假设在数据库中存在这样三张表: tb_stock 库存表，tb_order 订单表，tb_orderlog 订单日志表。
在进行数据备份时，先备份了tb_stock库存表。
然后接下来，在业务系统中，执行了下单操作，扣减库存，生成订单（更新tb_stock表，插入 tb_order表）。
然后再执行备份 tb_order表的逻辑。
业务中执行插入订单日志操作。
最后，又备份了tb_orderlog表
此时备份出来的数据，是存在问题的。因为备份出来的数据，tb_stock表与tb_order表的数据不一 致(有最新操作的订单信息,但是库存数没减)。
那如何来规避这种问题呢? 此时就可以借助于MySQL的全局锁来解决
B. 再来分析一下加了全局锁后的情况
对数据库进行进行逻辑备份之前，先对整个数据库加上全局锁，一旦加了全局锁之后，其他的DDL，DML全部都处于阻塞状态，但是可以执行DQL语句，也就是处于只读状态，而数据备份就是查询操作。 那么数据在进行逻辑备份的过程中，数据库中的数据就是不会发生变化的，这样就保证了数据的一致性和完整性。

4.1.2 语法

1). 加全局锁

flush tables with read lock ;

2). 数据备份

mysqldump -uroot --p1234 itcast > itcast.sql

3). 释放锁

unlock tables ;

4.1.3 特点

数据库中加全局锁，是一个比较重的操作，存在以下问题：
如果在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆。
如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志（binlog），会导
致主从延迟。
在InnoDB引擎中，我们可以在备份时加上参数 --single-transaction 参数来完成不加锁的一致
性数据备份。

mysqldump --single-transaction -uroot --p123456 itcast > itcast.sql

4.2 表级锁

4.2.1 介绍

表级锁，每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在MyISAM、InnoDB、BDB等存储引擎中。
对于表级锁，主要分为以下三类：
表锁
元数据锁（meta data lock，MDL）
意向锁

4.2.2 表锁

对于表锁，分为两类：
表共享读锁（read lock）
表独占写锁（write lock）
语法：
加锁：lock tables 表名... read/write。
释放锁：unlock tables / 客户端断开连接 。
特点:
A. 读锁
左侧为客户端一，对指定表加了读锁，不会影响右侧客户端二的读，但是会阻塞右侧客户端的写。
B. 写锁
左侧为客户端一，对指定表加了写锁，会阻塞右侧客户端的读和写。
结论 : 读锁不会阻塞其他客户端的读，但是会阻塞写。写锁既会阻塞其他客户端的读，又会阻塞
其他客户端的写。

4.2.3 元数据锁

meta data lock , 元数据锁，简写MDL。
MDL加锁过程是系统自动控制，无需显式使用，在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。为了避免DML与DDL冲突，保证读写的正确性。
这里的元数据，大家可以简单理解为就是一张表的表结构。 也就是说，某一张表涉及到未提交的事务时，是不能够修改这张表的表结构的。
在MySQL5.5中引入了MDL，当对一张表进行增删改查的时候，加MDL读锁(共享)；当对表结构进行变更操作的时候，加MDL写锁(排他)。
常见的SQL操作时，所添加的元数据锁：
当执行SELECT、INSERT、UPDATE、DELETE等语句时，添加的是元数据共享锁（SHARED_READ / SHARED_WRITE），之间是兼容的。
当执行SELECT语句时，添加的是元数据共享锁（SHARED_READ），会阻塞元数据排他锁
（EXCLUSIVE），之间是互斥的。

4.2.4 意向锁

1). 介绍
为了避免DML在执行时，加的行锁与表锁的冲突，在InnoDB中引入了意向锁，使得表锁不用检查每行数据是否加锁，使用意向锁来减少表锁的检查。
假如没有意向锁，客户端一对表加了行锁后，客户端二如何给表加表锁呢，来通过示意图简单分析一下：
首先客户端一，开启一个事务，然后执行DML操作，在执行DML语句时，会对涉及到的行加行锁。

当客户端二，想对这张表加表锁时，会检查当前表是否有对应的行锁，如果没有，则添加表锁，此时就会从第一行数据，检查到最后一行数据，效率较低。

有了意向锁之后 :
客户端一，在执行DML操作时，会对涉及的行加行锁，同时也会对该表加上意向锁。

而其他客户端，在对这张表加表锁的时候，会根据该表上所加的意向锁来判定是否可以成功加表锁，而不用逐行判断行锁情况了。
2). 分类
意向共享锁(IS): 由语句select ... lock in share mode添加 。 与 表锁共享锁 (read)兼容，与表锁排他锁(write)互斥。
意向排他锁(IX): 由insert、update、delete、select...for update添加 。与表锁共享锁(read)及排他锁(write)都互斥，意向锁之间不会互斥。
一旦事务提交了，意向共享锁、意向排他锁，都会自动释放。
A. 意向共享锁与表读锁是兼容的
B. 意向排他锁与表读锁、写锁都是互斥的

4.3 行级锁

4.3.1 介绍

行级锁，每次操作锁住对应的行数据。锁定粒度最小，发生锁冲突的概率最低，并发度最高。应用在InnoDB存储引擎中。
InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁。对于行级锁，主要分为以下三类：
行锁（Record Lock **）：**锁定单个行记录的锁，防止其他事务对此行进行update和delete。在RC、RR隔离级别下都支持。

间隙锁（Gap Lock **）：**锁定索引记录间隙（不含该记录），确保索引记录间隙不变，防止其他事
务在这个间隙进行insert，产生幻读。在RR隔离级别下都支持。
临键锁（Next-Key Lock **）：**行锁和间隙锁组合，同时锁住数据，并锁住数据前面的间隙Gap。
在RR隔离级别下支持。

4.3.2 行锁

1). 介绍
InnoDB实现了以下两种类型的行锁：
共享锁（S ）：允许多个事务同时读取同一行数据，但阻止其他事务对这行数据加排他锁（避免读取时被修改）。
例：

• 事务 A 需要读取一行数据（比如查询用户余额），先对这行加 S 锁。

• 此时事务 B 也想读取同一行，同样可以加 S 锁，两个事务能同时读取（共享读权限）。

• 但如果事务 C 想修改这行数据（需要加 X 锁），会被阻塞，必须等 A 和 B 的 S 锁释放后才能执行。
  S 锁之间不互斥（多个 S 锁可以共存），但 S 锁与 X 锁互斥（读和写不能同时进行）。
  排他锁（X ）：允许一个事务修改一行数据，同时完全阻止其他事务对这行数据加共享锁或排他锁（避免修改时被读取或其他修改）。
  例：

• 事务 A 需要修改一行数据（比如扣减用户余额），先对这行加 X 锁。

• 此时事务 B 想读取这行（加 S 锁）会被阻塞，事务 C 想修改这行（加 X 锁）也会被阻塞。

• 只有当 A 的 X 锁释放后，B 和 C 才能按顺序获取锁（S 或 X）。
  X 锁与任何锁（S 或 X）都互斥（写操作独占数据）。
  两种行锁的兼容情况如下:
  
  常见的SQL语句，在执行时，所加的行锁如下：
  
  2). 演示
  默认情况下，InnoDB在 REPEATABLE READ事务隔离级别运行，InnoDB使用 next-key 锁进行搜
  索和索引扫描，以防止幻读。
  针对唯一索引进行检索时，对已存在的记录进行等值匹配时，将会自动优化为行锁。
  InnoDB的行锁是针对于索引加的锁，不通过索引条件检索数据，那么InnoDB将对表中的所有记
  录加锁，此时 就会升级为表锁。因此，我们根据索引字段进行更新操作，就可以避免行锁升级为表锁的情况。
  可以通过以下SQL，查看意向锁及行锁的加锁情况：

  select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from
  performance_schema.data_locks;

A. 普通的select语句，执行时，不会加锁。

B. select...lock in share mode，加共享锁，共享锁与共享锁之间兼容。
共享锁与排他锁之间互斥。

客户端一获取的是id为1这行的共享锁，客户端二是可以获取id为3这行的排它锁的，因为不是同一行数据。 而如果客户端二想获取id为1这行的排他锁，会处于阻塞状态，以为共享锁与排他锁之间互斥。
C. 排它锁与排他锁之间互斥
当客户端一，执行update语句，会为id为1的记录加排他锁； 客户端二，如果也执行update语句更
新id为1的数据，也要为id为1的数据加排他锁，但是客户端二会处于阻塞状态，因为排他锁之间是互斥的。 直到客户端一，把事务提交了，才会把这一行的行锁释放，此时客户端二，解除阻塞。
D. 无索引行锁升级为表锁
stu表中数据如下:
我们在两个客户端中执行如下操作：

在客户端一中，开启事务，并执行update语句，更新name为Lily的数据，也就是id为19的记录 。
然后在客户端二中更新id为3的记录，却不能直接执行，会处于阻塞状态，为什么呢？
原因就是因为此时，客户端一，根据name字段进行更新时，name字段是没有索引的，如果没有索引，此时行锁会升级为表锁(因为行锁是对索引项加的锁，而name没有索引)。
接下来，我们再针对name字段建立索引，索引建立之后，再次做一个测试：
此时我们可以看到，客户端一，开启事务，然后依然是根据name进行更新。而客户端二，在更新id为3的数据时，更新成功，并未进入阻塞状态。 这样就说明，我们根据索引字段进行更新操作，就可以避免行锁升级为表锁的情况。

4.3.3 间隙锁&临键锁

默认情况下，InnoDB在 REPEATABLE READ事务隔离级别运行，InnoDB使用 next-key 锁进行搜
索和索引扫描，以防止幻读。
索引上的等值查询(唯一索引)，给不存在的记录加锁时, 优化为间隙锁 。
索引上的等值查询(非唯一普通索引)，向右遍历时最后一个值不满足查询需求时，next-key lock 退化为间隙锁。
索引上的范围查询(唯一索引)--会访问到不满足条件的第一个值为止。
注意：间隙锁唯一目的是防止其他事务插入间隙。间隙锁可以共存，一个事务采用的间隙锁不会
阻止另一个事务在同一间隙上采用间隙锁。
演示：
A. 索引上的等值查询(唯一索引)，给不存在的记录加锁时, 优化为间隙锁 。

B. 索引上的等值查询(非唯一普通索引)，向右遍历时最后一个值不满足查询需求时，next-key
lock 退化为间隙锁。
介绍分析一下：
我们知道InnoDB的B+树索引，叶子节点是有序的双向链表。 假如，我们要根据这个二级索引查询值为18的数据，并加上共享锁，我们是只锁定18这一行就可以了吗？ 并不是，因为是非唯一索引，这个结构中可能有多个18的存在，所以，在加锁时会继续往后找，找到一个不满足条件的值（当前案例中也就是29）。此时会对18加临键锁，并对29之前的间隙加锁。
C. 索引上的范围查询(唯一索引)--会访问到不满足条件的第一个值为止。
查询的条件为id>=19，并添加共享锁。 此时我们可以根据数据库表中现有的数据，将数据分为三个部分：

19

(19,25]
(25,+∞]
所以数据库数据在加锁是，就是将19加了行锁，25的临键锁（包含25及25之前的间隙），正无穷的临键锁(正无穷及之前的间隙)。