InnoDB Lock

浏览数：30 / 时间：2015年06月12日

众所周知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的时候，是时候好好检查一下了。因为真正的执行时间估计很短，时间是耗费在锁等待上面了。

总结：

innodb引擎有三种锁的算法设计：
Record lock：对单个索引项加锁
Gap lock：间隙锁，对索引项之间的"间隙",第一条记录前的"间隙"或最后一条记录后的"    间隙"加锁，不包括索引项本身
Next-key lock：Gap lock+Next-key lock 锁定索引项范围。对记录及其前面的间隙加锁
 
注意：
对于唯一索引，其加上的是Record Lock，仅锁住记录本身。但也有特别情况，那就是唯一索引由多个列组成，而查询仅是查找多个唯一索引列中的其中一个，那么加锁的情况依然是Next-key lock。
 
对于辅助索引，其加上的是Next-Key Lock，锁定的是范围，包含记录本身。
另外如果使用相等的条件给一个不存在的记录加锁，innodb也会使用Next-key lock
 
特别注意：
innodb存储引擎是通过给索引上的索引项加锁来实现，这意味着：只有通过索引条件检索数据，innodb才会使用行锁，否则，innodb将使用表锁。当然这种说法是在表没有主键或者没有任何索引的情况下。如果一个表有主键，没有其他的索引，检索条件又不是主键，SQL会走聚簇索引的全扫描进行过滤，由于过滤是由MySQL Server层面进行的。因此每条记录，无论是否满足条件，都会被加上X锁。但是，为了效率考量，MySQL做了优化，对于不满足条件的记录，会在判断后放锁，最终持有的，是满足条件的记录上的锁，但是不满足条件的记录上的加锁/放锁动作不会省略。同时，优化也违背了2PL的约束。

 

参考资料

<<MySQL技术内幕--InnoDB存储引擎第2版>> 

InnoDB Lock,古老的榕树,5-wow.com

郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。

标签： 算法 事务 class style 问题 使用 数据 com 算法 事务 class style 问题 使用 数据 com

相关文章

随机文章

您可能还喜欢

您可能还喜欢