可以看到会话B被阻塞了，而show engine innodb status\G看到的锁等待如下：
即insert语句想在(90,102)的gap上加个lock_mode=X的gap锁，也就是Insert Intention Lock，但是会话A的select for update语句已经在(100,102)的gap上添加了X模式的gap锁，这是一个与(90,102)不同但被包含在内的gap，于是被阻塞无法获取X模式的Insert Intention Gap Lock。
三、总结
MySQL的锁机制基本就如上所示了，但是了解InnoDB锁只是初步的，还必须结合事务隔离级别的概念去判断各种SQL的具体加锁机制，因为事务隔离级别会影响SQL的默认加锁模式。
MySQL的事务隔离级别定义也是遵循ANSI SQL92标准的，不过但凡是家数据库厂商都会说自己遵循SQL92标准，而事实是早已加料加的面目全非。当然这全都是为了能够提供更好的并发性能。例如Oracle也说自己遵循SQL92标准，结果四大隔离级别只支持2个，SQL Server也说自己支持，结果又多造出来2个事务隔离级别。
同样的MySQL也提供了4大基本的事务隔离级别，不同的隔离级别下加锁机制区别很大，参考：http://www.cnblogs.com/leohahah/p/8857124.html。
