间隙锁和死锁

间隙锁的表现
假设有一张表，test_innodb_lock表有a和b二个字段，a字段里面的数据缺了2,4,6,8，这些就是间隙，这个间隙引发的锁就叫做间隙锁，一般发生在范围查询里面。

将mysql数据库改为手动提交
步骤1：
窗口1：更新数据，update test_innodb_lock set b = 5 where a >1 and a < 9
窗口2：更新数据，insert into test_innodb_lock values(4,4)发现阻塞了，没有继续往下执行。

窗口1进行了一个范围查询，会把a >1 and a < 9加上锁，窗口2这个会话想插入2,4,6,8是无法插入的，因为它已经被窗口1的会话持有了锁。

死锁
死锁是指两个或两个以上的事务在执行过程中，因争夺锁资源而造成的一种互相等待的现象。若无外力作用，事务都将无法推进下去。

解决死锁问题最简单的方式是不要有等待，将任何的等待都转化为回滚，并且事务重新开始。但是在线上环境中，这可能导致并发性能的下降，甚至任何一 个事务都不能进行。而这所带来的问题远比死锁问题更为严重，因为这很难被发现并且浪费资源。

解决死锁问题的另一种方法是超时，即当两个事务互相等待时，当一个等待时间超过设置的某一阈值时，其中一个事务进行回滚，另一个等待的事务就能继续进行。

在InnoDB存储引擎中，参数innodb_lock_wait_timeout用来设置超时的时间。 超时机制虽然简单，但是其仅通过超时后对事务进行回滚的方式来处理，或者说其是根据FIFO的顺序选择回滚对象。但若超时的事务所占权重比较大，如事务操作更新了很多行，占用了较多的undo log，这时采用FIFO的方式， 就显得不合适了，因为回滚这个事务的时间相对另一个事务所占用的时间可能会很多。

因此，除了超时机制，当前数据库还都普遍采用wait-for graph（等待图）的方式来进行死锁检测。较之超时的解决方案，这是一种更为主动的死锁检测方式。InnoDB存储引擎也采用的这种方式。wait-for graph要求数据库保存以下两种信息： 锁的信息链表和事务等待链表。

wait-for graph是一种较为主动的死锁检测机制，在每个事务请求锁并发生等待时都会判断是否存在回路，若存在则有死锁，通常来说InnoDB存储引擎选择回滚undo量最小的事务。