关于GAP死锁的场景

场景是表中id从5到9的数据被删除，当事务A锁定id=6，事务B也锁定id=6，事务A插入会等待，事务B插入提示死锁， 事务B回滚，事务A提交。

数据如下：

REPEATABLE-READ隔离（默认）：
事务A执行插入：
显示锁类型是行锁，模式是排他、GAP锁。

事务B执行插入：
事务B回滚，事务A执行。

当我们通过一个参数去删除一条记录的时候， 如果参数在数据库中存在， 那么这个时候产生的是普通行锁， 锁住这个记录， 然后删除， 然后释放锁。如果这条记录不存在，问题就来了， 数据库会扫描索引，发现这个记录不存在， 这个时候的delete语句获取到的就是一个间隙锁，然后数据库会向左扫描扫到第一个比给定参数小的值， 向右扫描扫描到第一个比给定参数大的值， 然后以此为界，构建一个区间， 锁住整个区间内的数据， 一个特别容易出现死锁的间隙锁诞生了。

范围for update时，同样会有死锁的情况出现，不过这里的锁类型是排他锁。

可以证明的是，在innodb的默认RR隔离状态下，等值的for update有可能是间隙锁，当锁定的行是被范围删除行时，会造成排他间隙锁，这里的排他间隙锁，可以被多个事务添加，但是会造成之后的第一个事务的插入等待，之后的事务插入死锁。
注：
GAP锁是用来阻止在这个范围内进行插入，等值范围的GAP类型锁是可以互相兼容的。

Read-Committed隔离：
这里可以看出，锁是共享锁和排他锁，

在RR隔离下，事务A插入时成功，事务B插入时会等待。说明事务在RC隔离下，不会出现间隙锁，也就不会因为间隙锁而导致死锁。