gap Lock 间隙锁

InnoDB有三种行锁的算法：

1，Record Lock：是加在索引记录上的。

2，Gap Lock（间隙锁）：对索引记录间的范围加锁，或者加在最后一个索引记录的前面或者后面

3，Next-Key Lock：前两种锁的结合，锁定一个范围，并且锁定记录本身，主要目的是解决幻读的问题。

间隙锁主要是防止幻象读，用在Repeated-Read（简称RR）隔离级别下。在Read-Commited（简称RC）下，一般没有间隙锁（有外键情况下例外，此处不考虑）。间隙锁还用于statement based replication

间隙锁有些副作用，如果要关闭，一是将会话隔离级别改到RC下，或者开启 innodb_locks_unsafe_for_binlog（默认是OFF）。

间隙锁（无论是S还是X）只会阻塞insert操作。

| id | k |

+—-+——+

| 10 | 10 |
除了对于k=5这条记录上record lock之外，innoDB对于delete和update在辅助索引(非主键索引)上的条件时会对扫过的记录上间隙锁，为了防止幻读，会锁住k=5这条记录的前面一条记录（id=2,k=2）到后面一条记录(id=10,k=10)之间的区间，即锁住k在区间(2,10)的范围(如果没有后一条记录，一直锁到正无穷)，至于在边界k=2及k=10上，由于索引内是按照主键排序的，不会锁住(id<2,k=2)但是会锁住(id>2,k=2)，同理不会锁住(id>10,k=10)但是会锁住(id<10,k=10)
值得注意的是，delete和update在唯一索引（primary key/unique key）上更新存在的记录时只会上行级记录锁（record key），而在唯一索引上更新不存在的记录时同辅助索引一样会上间隙锁；在上例中,delete id=5只会在(id=5,k=5)这条记录上上X锁，而delete id=7却会锁住（id>5&&id<10）这个区间。

默认情况下，InnoDB工作在可重复读隔离级别下，并且以Next-Key Lock的方式对数据行进行加锁，这样可以有效防止幻读的发生。Next-Key Lock是行锁与间隙锁的组合，这样，当InnoDB扫描索引记录的时候，会首先对选中的索引记录加上行锁（Record Lock），再对索引记录两边的间隙（向左扫描扫到第一个比给定参数小的值， 向右扫描扫描到第一个比给定参数大的值， 然后以此为界，构建一个区间）加上间隙锁（Gap Lock）。如果一个间隙被事务T1加了锁，其它事务是不能在这个间隙插入记录的

InnoDB行锁是通过给索引上的索引项加锁来实现的，只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁。
任何辅助索引上的锁，或者非索引列上的锁，最终都要回溯到主键上，在主键上也要加一把锁。

间隙锁的目的是为了防止幻读，其主要通过两个方面实现这个目的：
（1）防止间隙内有新数据被插入
（2）防止已存在的数据，更新成间隙内的数据（例如防止numer=3的记录通过update变成number=5）

innodb自动使用间隙锁的条件：
（1）必须在RR级别下
（2）检索条件必须有索引（没有索引的话，mysql会全表扫描，那样会锁定整张表所有的记录，包括不存在的记录，此时其他事务不能修改不能删除不能添加）

InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求
另外一方面，是为了满足其恢复和复制的需要
InnoDB这种加锁机制会阻塞符合条件范围内键值的并发插入，这往往会造成严重的锁等待。因此，在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。

select * from t where id = 10 for update;// 注意：普通查询是快照读，不需要加锁
上面语句中id列没有建立索引或者是非唯一索引时，则语句会产生间隙锁。
搜索条件里有多个查询条件(即使每个列都有唯一索引)，也是会有间隙锁的。