http://dev.mysql.com/doc/refman/5.6/en/innodb-locks-set.html
前置：检索如果用不到索引，会扫描全表，并根据策略加锁。所以，这就是我们合理建立索引的缘由。
锁定读、Update、Delete，在处理sql过程中， 一般会在每条扫描过的索引记录上设置记录锁。语句中是否有where条件并没有关系（会排除）。InnoDB不会记住实际上的Where条件，但他知道被扫描过的索引范围。使用的锁通常是next-key锁，也会锁住记录之前的“gap”。Next-Key锁不仅仅锁住扫描到的合法索引记录，同时会阻塞插入gap间隙中，gap是指上一条合法索引记录到当前扫描到的合法索引记录的开区间。gap锁可以被显示的禁止，导致next-key不会被使用。
事物的隔离级别同样会影响使用什么锁。
如果一个二级索引被用来扫描，且索引记录（二级索引，非唯一索引）将要加排他锁，InnoDB会检索相对应的聚簇索引记录，并锁住。
聚簇索引(clustered index)
1) 有主键时，根据主键创建聚簇索引
2) 没有主键时，会用一个唯一且不为空的索引列做为主键，成为此表的聚簇索引
3) 如果以上两个都不满足那innodb自己创建一个虚拟的聚集索引
辅助索引(secondary index)
非聚簇索引都是辅助索引，像复合索引、前缀索引、唯一索引
如果没有合适的索引使用，MySQL会扫面整张表，来处理语句，这样表中的每一行都会被锁住（合理建立索引，提高并发效率）。
对于 SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE，扫描到的行都会锁住，并且期望在有些row不会加入结果集中（例如不满足Where条件）释放这些行的锁。注：其实扫描了全表，只不过在扫描完成之后，判断Where条件时不满足，则会释放锁。然而对于某些情况下，不会立即释放行锁，因为在查询执行期间一个结果行和他的原始来源之间的关系可能已经丢失，例如Union，从表中扫描行，在计算他们是否加入结果集之前，这些行可能被插入临时表中。此时，临时表中的行和原始表中的行的关系已经丢失，原始表中的行不会解锁知道查询执行完成。
InnoDB按照如下设置具体的锁：
SELECT ... FROM 是一个一致性非锁定读，读取数据库的快照，不会加锁，除非隔离级别为S。对于S隔离级别，检索结果集在索引记录项上使用共享锁且是next-key锁。但是，当唯一确定记录时，next-key锁会降级为记录锁。SELECT ... FROM ... LOCK IN SHARE MODE 在检索到的所有索引记录上设置共享锁且是next-key锁。但是，当唯一确定记录时，next-key锁会降级为记录锁。SELECT ... FROM ... FOR UPDATE在检索到的每条记录上的每一个记录上加排他锁且是next-key锁。但是，当唯一确定记录时，next-key锁会降级为记录锁。对索引记录加的排他锁阻塞共享锁和某些隔离级别的操作读。一致性非锁定读，会忽略任何锁。UPDATE ... WHERE ...在检索到的每条记录上的每一个记录上加排他锁且是next-key锁。但是，当唯一确定记录时，next-key锁会降级为记录锁。- 当Update修改一个聚簇索引记录，隐式的锁会加在受影响的（将要更新的字段）的二级索引记录（不是全部索引记录，Where字段指定范围）上。Update操作同样会加共享锁在受影响的二级索引记录上，当在插入一个新的二级索引记录之前执行重复检查时，或者当插入一个新的二级索引记录时。
DELETE FROM ... WHERE ... 在检索到的每条记录上的每一个记录上加排他锁且是next-key锁。但是，当唯一确定记录时，next-key锁会降级为记录锁。INSERT 设置一个排它锁在插入的行上，这是一个记录锁，不是next-key，就是说没有gap锁，不会阻止其他事物插入被插记录之前的gap中。
在插入之前，一种叫插入意向锁的gap类型锁，被设置，这个锁表示对事物插入同一个gap中时，不需要相互等待，只要他们不是插入gap中相同的位置。
设置插入操作的排他锁之前，现货去gap的插入意向锁，俩个事物可以在同一个gap（重叠也可以）加插入意向锁不会阻塞。
如果有重复冲突，一个共享锁在重复的索引记录上设置。共享锁的使用可能导致死锁：当多个会话插入相同的行时，如果有某个会话已经持有了X锁，此时会导致死锁。举个例子：如果有某个会话删除该行，另外俩个插入行，则会死锁。
Session 1:
START TRANSACTION; INSERT INTO t1 VALUES(1);Session 2:
START TRANSACTION; INSERT INTO t1 VALUES(1);Session 3:
START TRANSACTION; INSERT INTO t1 VALUES(1);Session 1:
ROLLBACK;
上述情况是会话1已经获取了x锁在r行上，会话2和4都会引起重复键冲突，俩个会话都转而去请求r行共享锁，当会话1回滚时，它释放他的排它锁，会话2和3的共享锁请求被授予，此时，会话2和3死锁：没有任何一个会获取排它锁，因为他们都持有了共享锁。
Session 1:
START TRANSACTION; DELETE FROM t1 WHERE i = 1;Session 2:
START TRANSACTION; INSERT INTO t1 VALUES(1);Session 3:
START TRANSACTION; INSERT INTO t1 VALUES(1);Session 1:
COMMIT;
上述情况和第一种类似。
INSERT ... ON DUPLICATE KEY UPDATE 不同与简单的Insert，当重复值冲突时，加的锁是一个排它next-key锁而不是一个共享锁-记录锁。REPLACE 如果在唯一key上没有冲突，像INSERT一样加锁。够则像INSERT ... ON DUPLICATE KEY UPDATE一样- INSERT INTO T SELECT ... FROM S WHERE ... 在插入T表中的每一行上加一个排它记录锁，注意没有gap。如果事物级别是RC，或者启用了
innodb_locks_unsafe_for_binlog（此时不能是隔离级别S），InnoDB在S表上是一致性非锁定读（不加锁）。否则，InnoDB会设置共享的next-key锁到从S表检索结果中的行。
CREATE TABLE ... SELECT ... 执行 SELECT使用共享的next-key锁，或者一致性非锁定读，就像 INSERT ... SELECT.一样.
当一个SELECT在类似REPLACE INTO t SELECT ... FROM s WHERE ... or UPDATE t ... WHERE col IN (SELECT ... FROM s ...)的结果中，InnoDB设置共享且next-key锁在表S上的行上。
- 当初始化表中先前指定的AUTO_COMMIT列时，InnoDB设置一把排它锁在与AUTO_COMMIT列相关的索引的尾部，在访问自动增长计数器时，InnoDB使用的是特殊的AUTO-INC表级锁模式，该锁在语句执行完成之后释放，而不是在事物结束的时候释放，所以性能也不是太糟。InnoDB获取先前已经初始化的AUTO_COMMIT列时，不需要加任何的锁。
- 如果一个外键约束定义在表中，任何要求约束检查的插入、更新和删除设置一把共享行锁到到特定的外键记录上，以便检查约束。
LOCK TABLES 设置表级锁