三、 InnodDB行锁实现方式
InnoDB行锁是通过给索引上的索引项加锁来实现的。这一点Mysql和Oracle不同，Oracle是通过直接在数据块中对相应数据行加锁来实现的。
InnoDB的这种特性意味着：只有通过索引条件检索数据，InnoDB才使用行级锁；否则InnoDB将使用表锁。
1）非索引字段加锁变成表锁
表20-9 InnoDB存储引擎的表在不使用索引时使用表锁例子
注意，对于表没有加索引，线程A仅要求获取id=1的记录的独占锁，但是因为没有加索引，所以该语句锁住了整个表，使用了表锁。
当我们对id行添加索引
alter table tab_with_index add index id(id);
则会有下面的例子：
2）相同索引键导致阻塞
由于Mysql的行锁是针对索引加的锁，而不是针对记录加的，所以即使是访问不同行，但是如果使用了相同的索引键，依然会冲突：
mysql> select * from tab_with_index where id = 1; ±-----±-----+ | id | name | ±-----±-----+ | 1 | 1 | | 1 | 4 | ±-----±-----+
例如对于上表，如果对id加了索引，但是有两个记录的id相同，也就是索引相同。此时两个线程分别试图获取两个记录的独占锁依然会导致阻塞，因为mysql的行锁是加在索引上的。
3）不同索引键指向同一行记录也会导致阻塞
mysql> alter table tab_with_index add index name(name);
alter table tab_with_index add index id(id);
假设我们分别对id和name增加索引，那么不管是什么索引，InnoDB都会使用行锁来锁定不同的行。
如果是不同的索引，但是指向了同一条记录，那么依然会导致阻塞。
我的理解是不同索引最后指向了同一条主键id，锁住了注解id，故依然会阻塞，应该不是锁住记录。
4）间隙锁
当我们使用范围条件而不是相等条件来检索数据，并请求共享或排他锁时，InnoDB会给所有符合条件的已有数据记录的索引加锁；对于键值在条件范围内但是并不存在的记录，叫做间隙gap，InnoDB也会对这些间隙加锁。这种锁机制就是间隙锁。
举例来说，假如emp表中只有101条记录，其empid的值分别是 1,2,…,100,101，下面的SQL：
Select * from emp where empid > 100 for update;
这是一个范围条件的检索，InnoDB不仅会对empid为101的记录加锁，对于大于101的不存在间隙也会加锁。
**Mysql使用间隙锁的目的是防止幻读（应该只是一部分满足，不能完全回避），以满足相关隔离级别的要求。**比如对于上面的情况，如果不加锁，那么其他事务插入了empid为102的记录，则会导致本事务内再次执行上述语句时得到empid为102的记录，也就导致了幻读。另一方面，也是为了满足其回复和复制的需要。
因此，在使用范围条件检索并锁定记录时，InnoDB的这种间隙加锁机制会阻塞符合条件范围内键值的并发插入，从而导致严重的锁等待。因此，对于并发插入较多的应用，我们要尽量优化业务逻辑，尽量用相等条件来访问更新数据，避免使用范围条件。
还要特别说明的是，InnoDB除了通过范围条件加锁时使用间隙锁外，如果使用相等条件请求给一个不存在的记录加锁，InnoDB也会使用间隙锁！
5）关于恢复和复制的需要，对InnoDB锁机制的影响
Mysql通过BINLog记录执行成功的INSERT、UPDATE、DELETE等更新数据的SQL语句，并由此实现MySQL数据库的回复和主从复制。Mysql的恢复记录（复制实际就是在Slave Mysql不断的做基于BINLOG的恢复）有以下特点：
一是MySQL的恢复是SQL语句级的，也就是重新执行BINLOG中的SQL语句。
二是MySQL的Binlog是按照事务提交的先后顺序记录的，恢复也是按这个顺序进行的。
**根据上述的特点，Mysql的恢复机制要求：在一个事务未提交前，其他并发事务不能插入满足其锁定条件的任何记录，也就是不允许出现幻读。****这已经超过了ISO/ANSI SQL92“可重复读”隔离级别的要求，实际上是要求事务要串行化。这也是许多情况下，InnoDB要用到间隙锁的原因。**比如在用范围条件更新记录时，无论是Read Commited还是Repeatable Read隔离级别，InnoDB都要使用间隙锁，这并不是隔离级别的要求，而是由于Mysql恢复和复制的要求。
