众所周知innodb的锁是行级锁，这样说也没有问题，只是还可以细分而已。推荐阅读何登成大牛的博客http://hedengcheng.com/?p=771
innodb的锁有三种算法，分别如下：
Read Lock：单个记录上的锁
Gap Lock：间隙锁，锁定一个范围，但不包含记录本身
Next-Key Lock：Gap Lock+Record Lock，锁定一个范围，并且锁定记录本身
Record Lock 总是会去锁住索引记录，如果innodb存储引擎表在建立的时候没有设置任何一个索引，而且查询的时候没有使用到索引，那么这时就会导致表锁。
Next-Key Lock是结合了Gap Lock和Record Lock的一种锁定算法，在Next-Key Lock算法下，innodb对于行的查询都是采用这种锁定算法。例如一个索引有10,11,13,20这4
个值，那么该索引可能被Next-Key Locking的范围为：
(- &，10]
(10,11]
(13,20]
(20,+ &)
采用Next-Key Lock的锁定技术称为Next-Key Locking。这种设计的目的是为了解决幻读（Phantom Problem）。关于幻读请同学们自行了解MySQL的4个隔离级别及存在的问
题。利用这种锁定技术，锁定的不是单个值，而是一个范围。
注：当查询的索引含有唯一属性时，innodb存储引擎会对Next-Key Lock进行优化，将其降级为Record Lock，即锁住索引记录本身，而不再是范围。
测试数据如下：
root@localhost : yayun 01:00:29> create table t1 ( id int primary key); Query OK, 0 rows affected (0.03 sec) root@localhost : yayun 01:00:31> insert into t1 ( id ) values (1),(2),(5); Query OK, 3 rows affected (0.06 sec) Records: 3 Duplicates: 0 Warnings: 0 root@localhost : yayun 01:01:00> select * from t1; +----+ | id | +----+ | 1 | | 2 | | 5 | +----+ 3 rows in set (0.04 sec) root@localhost : yayun 01:01:08>
看看隔离级别
root@localhost : yayun 01:20:20> show variables like ‘%iso%‘; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | tx_isolation | REPEATABLE-READ | +---------------+-----------------+ 1 row in set (0.12 sec) root@localhost : yayun 01:20:35>
执行相应的测试SQL语句：
会话A的操作：
root@localhost : yayun 01:20:35> begin; Query OK, 0 rows affected (0.00 sec) root@localhost : yayun 01:21:31> select * from t1 where id=5 for update; +----+ | id | +----+ | 5 | +----+ 1 row in set (0.08 sec) root@localhost : yayun 01:21:52>
会话B的操作（可以看见成功提交，并没有发生锁等待）：
root@localhost : yayun 01:20:11> begin; Query OK, 0 rows affected (0.00 sec) root@localhost : yayun 01:22:30> insert into t1 select 4; Query OK, 1 row affected (0.05 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 01:22:45> commit; Query OK, 0 rows affected (0.00 sec) root@localhost : yayun 01:22:49>
表t1共有1,2,5三个值。上面的示例中，在会话A首先对id=5进行X锁定。但是由于id是主键且唯一，所以锁定的仅仅是5这个值而已。而不是（2 ，5）这个范围，所以会话B中插入值4不会导致阻塞，可以立即插入提交成功。即这时候Next-Key Lock算法降级为Record Lock，仅锁住记录本身，从而提高并发性。
证实了文章开始提到的：Next-Key Lock降级为Recod Lock仅在查询的列是唯一索引的情况下。若是辅助索引，那么情况则会完全的不同。测试示例如下：
root@localhost : yayun 01:34:50> create table t2 ( id int, vid int, primary key (id), key(vid)); Query OK, 0 rows affected (0.50 sec) root@localhost : yayun 01:34:53> insert into t2 select 1,1; Query OK, 1 row affected (0.01 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 01:35:07> insert into t2 select 3,1; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 01:35:14> insert into t2 select 5,3; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 01:35:19> insert into t2 select 7,6; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 01:35:24> insert into t2 select 10,8; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 01:35:31>
表t2的列vid列是辅助索引，在A会话执行下面的SQL语句：
root@localhost : yayun 01:38:43> begin; Query OK, 0 rows affected (0.00 sec) root@localhost : yayun 01:38:46> select * from t2 where vid=3 for update; +----+------+ | id | vid | +----+------+ | 5 | 3 | +----+------+ 1 row in set (0.00 sec) root@localhost : yayun 01:38:49>
很明显这时的SQL语句通过索引列vid进行查询，因此将会使用传统的Next-Key Locking技术加锁，并且由于有两个索引，需要分别进行锁定。对于聚集索引，仅对列id等于5的索引加上Record Lock，即只锁住5这个记录。而对于辅助索引，其加上的Next-Key Lock，锁定的范围是（1 ，3）的记录，特别需要注意innodb存储引擎还会对辅助索引下一个键值加上Gap Lock，即还有一个辅助索引范围为（3 ，6）的锁。因此新会话B中运行下面的SQL语句，都会被阻塞。
select * from t2 where id=5 lock in share mode; insert into t2 select 4,2; insert into t2 select 6,5;
调整一下锁超时，让测试更加方便快捷^_^
root@localhost : yayun 01:53:21> set global lock_wait_timeout=3; Query OK, 0 rows affected (0.00 sec) root@localhost : yayun 01:53:44>
会话B中操作如下：
root@localhost : yayun 01:56:40> begin; Query OK, 0 rows affected (0.00 sec) root@localhost : yayun 01:56:42> select * from t2 where id=5 lock in share mode; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction root@localhost : yayun 01:56:56> root@localhost : yayun 01:57:16> insert into t2 select 4,2; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction root@localhost : yayun 01:57:37> root@localhost : yayun 01:57:38> insert into t2 select 6,5; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction root@localhost : yayun 01:58:02>
可以看见上面列出的SQL都无法执行成功。被阻塞了。
第一个SQL语句不能执行是因为会话A中执行的SQL语句已经对聚集索引中列id=5的值加上了X锁，因此执行会被阻塞。第二个SQL语句，主键插入4，没有问题，但是插入的辅助索引值2在锁定的范围（1 ，3）中，因此执行同样会被阻塞。第三个SQL语句，插入的主键6没有被锁定，5也不在范围（1 ，3）之间。但插入的值5在另一个锁定的范围（3 ，6）中，故同样被锁定。相反，下面的SQL语句不会被阻塞。可以立即执行。
insert into t2 select 8,6； insert into t2 select 2,0； insert into t2 select 6,7；
在会话B中操作如下：
root@localhost : yayun 01:58:02> insert into t2 select 8,6; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 02:06:43> insert into t2 select 2,0; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 02:06:49> insert into t2 select 6,7; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 02:06:55>
都执行成功，没有一条被阻塞。
从上面的例子可以看到，Gap Lock的作用是为了阻止多个事务将记录插入到同一范围内，而这会导致Phantom Problem问题的产生。比如在上面的例子中，会话A中已经锁定vid=3的记录，若此时没有Gap Lock锁定（3 ，6），那么另外的用户可以插入索引列为3的记录。这将导致会话A中的用户再次执行同样的查询会返回不同的记录。这就会导致幻读（Phantom Problem）问题的产生。
我们也可以通过2种方式来显示的关闭Gap Lock：
（1）将事务的隔离级别设置为READ COMMITIED
（2）调整参数innodb_locks_unsafe_for_binlog为1
在上面的配置下，除了外键约束和唯一性检查依然需要使用Gap Lock，其余情况仅使用Record Lock进行锁定。但是通常我们不能这么干，上面的设置破坏了事务的隔离性，并且对于replication，可能会导致主从复制数据不一致。为什么会这样请参看我前面的文章。此外，从性能上来看，READ COMMITIED也不会优与默认的事务隔离级别READ REPEATABLE。
在innodb引擎中，对于INSERT操作，其会检查插入的记录的下一条记录是否会被锁定，若已经锁定，则不允许插入。
在会话A中已经锁定了表t2中vid=3的记录，即已经锁定了（1 ，3）的范围，这时若在会话B中进行如下的插入同样会被阻塞：
root@localhost : yayun 02:22:17> insert into t2 select 2,2; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction root@localhost : yayun 02:22:24>
因为在辅助索引列vid上插入值为2的记录时，会监测到下一个记录3已经被锁定。如果我们执行下面的SQL则可以正常插入。
root@localhost : yayun 02:22:24> insert into t2 select 2,0; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 02:27:08>
还有两种特殊的情况需要注意：
（1）innodb表没有可使用的索引时，将采用表锁。
（2）查询仅仅是查找多个唯一索引列中的其中一个，那么查询其实就是range类型查询，innodb将依然使用Next-Key Lock算法进行锁定。
示例如下，首先先看没有索引可用的情况（1）
root@localhost : yayun 02:33:36> create table t3 ( id int, name char(20)); Query OK, 0 rows affected (0.04 sec) root@localhost : yayun 02:33:40> insert into t3 select 1,‘yayun‘; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 02:33:44> insert into t3 select 2,‘yy‘; Query OK, 1 row affected (0.01 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 02:33:50> insert into t3 select 3,‘mysql‘; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 02:34:02>
root@localhost : yayun 02:36:35> show create table t3\G *************************** 1. row *************************** Table: t3 Create Table: CREATE TABLE `t3` ( `id` int(11) DEFAULT NULL, `name` char(20) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 1 row in set (0.00 sec) root@localhost : yayun 02:38:53>
会话A的操作如下：
root@localhost : yayun 02:35:03> begin; Query OK, 0 rows affected (0.00 sec) root@localhost : yayun 02:35:11> update t3 set name=‘yayun‘ where id=2; Query OK, 1 row affected (0.04 sec) Rows matched: 1 Changed: 1 Warnings: 0 root@localhost : yayun 02:36:35>
会话B的操作如下：
root@localhost : yayun 02:34:51> begin; Query OK, 0 rows affected (0.00 sec) root@localhost : yayun 02:37:17> update t3 set name=‘yayun‘ where id=3; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction root@localhost : yayun 02:38:06> root@localhost : yayun 02:38:08>
可以看出，只有通过索引检索数据，innodb才会采用行锁，否则，innodb将会使用表锁。生产环境一定要注意。
下面看看对于查询的列是唯一索引列，且唯一索引列由多个列组成，innodb采用什么锁算法。
示例如下：
root@localhost : yayun 02:43:49> create table t4 ( id int , uid int, unique key(id,uid))engine=innodb; Query OK, 0 rows affected (0.04 sec) root@localhost : yayun 02:45:15> insert into t4 select 1,2; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 02:45:45> insert into t4 select 1,3; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 02:45:48> insert into t4 select 1,5; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 02:45:51> insert into t4 select 1,8; Query OK, 1 row affected (0.00 sec) Records: 1 Duplicates: 0 Warnings: 0 root@localhost : yayun 02:45:54>
上面我创建了一个唯一索引，是由id，uid两个字段组成。
会话A的操作如下：
root@localhost : yayun 02:47:31> begin; Query OK, 0 rows affected (0.00 sec) root@localhost : yayun 02:47:36> select * from t4 where uid=5 for update; +------+------+ | id | uid | +------+------+ | 1 | 5 | +------+------+ 1 row in set (0.03 sec) root@localhost : yayun 02:49:30>
会话B的操作如下：
root@localhost : yayun 02:43:56> begin; Query OK, 0 rows affected (0.00 sec) root@localhost : yayun 02:50:01> insert into t4 select 1,2; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction root@localhost : yayun 02:50:58> root@localhost : yayun 02:50:59> insert into t4 select 1,4; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction root@localhost : yayun 02:51:19> root@localhost : yayun 02:51:30> insert into t4 select 1,6; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction root@localhost : yayun 02:51:45> root@localhost : yayun 02:51:46> insert into t4 select 1,8; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction root@localhost : yayun 02:51:53>
可见依然采用的是Next-Key Lock进行锁定的。不再重复。说了这么多相信大家都有一个初步印象了，当你发现生产环境中一个update语句就执行了30s，40s的时候，是时候好好检查一下了。因为真正的执行时间估计很短，时间是耗费在锁等待上面了。
总结：
参考资料
<<MySQL技术内幕--InnoDB存储引擎第2版>>
原文：http://www.cnblogs.com/gomysql/p/3898458.html