Innodb 锁类型：
说明：本文中如无特殊说明，默认为innodb引擎，事务隔离级别为RR。
Shared and Exclusive Locks
innodb 可以通过两种方式实现行级锁定，即Shared(S) lock和Exclusive Lock (X)。以下简称为S锁和X锁。
S锁为共享锁，持有S锁的事务可以对该行进行读取操作，且其他session对该行不可修改。
X锁为排他锁，持有X锁的事务可以对该行进行修改操作。
如果一条记录被加了S锁，那么其他事务仍可以对其加S锁。
如果一条记录被加了X锁，那么其他事务不可以对其他加S锁或者X锁。
下面一些情况会加S锁：
select ... lock in share mode , insert select ( select 中扫描到的记录), update 连表更新中不进行更新的表 ，
IF EXISTS(select 中扫描到的记录 ) ，使用外键时会对父键进行锁定 ...
下面一些情况会加X锁：
select ... for update , update 中要更新的内容 ...
S锁和X锁对相同记录的加锁一定要保持合理的顺序，否则会很容易造成死锁。
另外，从支持资源并发的角度出发，写各种语句一定要注意扫描的记录数，不仅仅是效率问题，更重要的是资源的利用最大化。
正确的认识X锁和S锁，对于资源的利用以及死锁查找是非常重要的。
Intention Locks
意向锁主要是为了支持多粒度锁机制而存在的一种锁，它不是由程序员去用程序控制，而是mysql自己来控制的。
举个例子来说明mysql的意向锁：
商场的一卫生间每晚都要进行锁门，清洁工大爷每天锁门前先进去挨个检查下了五个隔断是否有人，没有人了方可把卫生间落锁。
大爷觉得每天都要这样检查太麻烦，有没有一种办法我在门外都知道里面有没有人？有一天他终于想到了一个办法，他在门外挂了一个牌子，
正面写着“没人”，反面写着“有人”，而且他给所有上卫生间的人两条准则：
1 进入卫生间前，如果牌子是“没人”，那么一定要把牌子翻过来（“有人”）。
2 离开卫生间后，要检查下5个隔断，如果有人就直接离开，没人了要把牌子翻过来（“没人”）。
传说所有人都这样做了，然后老大爷晚上锁门的时候直接看下门口的牌子就可以决定锁门与否，再也不用自己进去检查了。
在上面的例子中，假设卫生间是一个数据表，里面的每一个隔断是一个数据行，那么卫生间门外的牌子就是意向锁。
Record Locks
Record lock是锁在索引上的，即使没有数据表没有索引，mysql会锁定聚簇索引。
Gap Locks
gap锁锁住的是索引的间隙，主要为了防止幻读的发生。
例如：有一表名为gap，里面有字段c2，c2上有索引（非唯一索引），目前c2有值为 2，4，7,10,几个值。
现在开启一个连接：
1 开始事务
2 更新c2值为4的记录 ： update gap set remark = 'change' where c2 = 7;
(事务未提交)
现在开启另外一个连接：
1 开启一个事务
2 此时，测试会发现
> insert gap(c2, remark) values(3,'');
// success
> insert gap(c2, remark) values(5,'');
//block
> insert gap(c2, remark) values(8,'');
//block
可以看出，在更新c2=7的记录时，(4,7) 与 （7,10）之间的记录都被锁住了，不能进行插入。
现在，如果把c2的索引修改为唯一索引，再次执行上面的例子，结果又会不一样，上面的三条记录全部都可以插入。
因此，在唯一索引上加锁是不会产生gap锁的。在生产中，如果使用for update 进行记录锁定时，where后尽量使用unique字段。
RR级别下，可以通过设置系统变量innodb_locks_unsafe_for_binlog来使Gap lock 禁用（在查询或者索引被扫描的时候）。
另外，如果删除或者更新的记录是通过唯一键进行扫描的时候，将不会有gap锁产生。（因此，在进行对记录的更改时，where后面最好用主键或者唯一键扫描，避免gap锁）
Next-Key Locks
next-key lock = record lock + gap lock;