系统在高并发情况下，经常出现insert死锁，经过排查是间隙锁在作怪！
MySQL InnoDB支持三种行锁方式：
行锁（Record Lock）:也叫记录锁，锁直接加在索引记录上。
间隙锁（Gap Lock）:锁加在不存在的空闲空间，可以是两个索引记录之间，也可能是第一个索引记录之前或最后一个索引记录之后的空间。
Next-Key Lock:行锁与间隙锁组合起来用就叫做Next-Key Lock.
默认情况，InnoDB工作在Repeatable Read 隔离级别下，对主健索引，唯一性索引以记录锁方式对数据进行加锁，对普通索引以Next-Key Lock的方式对数据行进行加锁。如果一个间隙被事务加了锁，其它事务这时不能在这个间隙插入记录的，这样可以有效防止幻读的发生。
若要禁用间隙锁的话，可以把隔离级别降到Read Commited 或者开启参数innodb_locks_unsafe_for_binlog（默认值为OFF,即启用间隙锁，若设置为true,则不启用间隙锁）,但是修改这个参数会影响主从复制及灾难恢复，所以只有修改代码逻辑才是比较好的解决办法。
间隙锁的出现主要集中在同一个事物中先delete后insert的情况下，我们通过一个参数条件去删除一条记录的时候，如果参数条件存在，那么这时产生的是普通行锁，锁住这个记录，然后进行删除，随后释放行锁。如果这参数条件记录不存在，这时候delete语句获取到一个间隙锁，然后数据库会向左扫描到第一个比当前参数小的值，向右扫描到第一个比给定参数大的值，然后以此为界，锁住整个区域内的数据，就这样一个特别容易产生死锁的间隙锁诞生了。
举例：
表student
id grade
1 79
2 80
15 90
30 98
开启一个客户端会话：
sql>set autocommit=0; （取消自动提交）
sql>delete from student where grade=90;
sql>insert into student values(20,100);
在没有并发或是极少并发的情况下，这样会可能会正常执行，在Mysql中，实际事务都是穿行执行的，在高并发情况下，执行顺序就极有可能发生改变，变成下面样子：
sql>delete from student where grade=90;
sql>delete from student where grade=91;
sql>insert into student values(15,90);
sql>insert into student values(25,99);
这个时候最后一条语句：insert into student values(25,99);执行时就会爆发死锁错误。因为删除grade=91这条记录的时候，90--98都被锁住，他们都取得了这个数据段的共享锁，所以在获取这个数据段的排它锁时出现死锁。
这种问题的解决办法：前面有说降低隔离级别会影响主从复制及灾难恢复，所以建议最好修改代码逻辑，存在才删除，尽量不要去删除不存在的记录。
，