关于Mysql的InnoDB锁概述

一 概述

InnoDB与MyISAM有两处不同：

1）InnoDB支持事务；

2）默认采用行级锁（也可以支持表级锁）

对于更新操作（UPDATE、INSERT、DELETE），InnoDB会自动给涉及到的数据集加排他锁（X）；对于普通的SELECT语句，InnoDB不加任何锁（所以即使有一个线程的写操作在占用锁，不影响其他线程的读，但是如果某个线程试图加共享锁则不行）。

InnoDB的行锁模式及加锁方法 InnoDB实现了以下两种类型的行锁。 共享锁(S)：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁； 排他锁(X)：允许获得排他锁的事务更新数据，阻止其他事务获得相同数据集的共享读锁和排他写锁。

另外，为了允许行锁和表锁共存，InnoDB还有两张内部使用的意向锁，都是表锁： 意向共享锁(IS)：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前先必须取得该表的意向共享锁； 意向排他锁(IX)：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的意向排他锁。 上述几种锁的兼容性如下： 表20-6 InnoDB行锁模式兼容性列表

如果一个事务请求的锁模式与当前的锁兼容，InnoDB就将请求的锁授予该事务；反之，如果两者不兼容，该事务就要等待锁释放。 意向锁是InnoDB自动加的，不需用户干预。 对于更新操作（UPDATE、INSERT、DELETE），InnoDB会自动给涉及到的数据集加排他锁（X）；对于普通的SELECT语句，InnoDB不加任何锁（所以即使有一个线程的写操作在占用锁，不影响其他线程的读，但是如果某个线程试图加共享锁则不行）。

显式的给记录集加共享锁：

• 共享锁： SELECT * FROM tableName WHERE …. LOCK IN SHARE MODE
• 排他锁： SELECT * FROM tableName WHERE …. FOR UPDATE

二、 共享锁中执行update操作容易导致死锁

注意：**用共享锁然后执行了update操作，则有可能和别的线程的update操作发生锁冲突，从而死锁。死锁后Mysql会自动关闭一个线程的事务操作，让锁被一个线程使用。**如下所示：

1）线程A和线程B对同一行记录使用了共享锁，两个线程读都没有问题（读不需要加锁，不管当前记录加了共享锁还是排他锁，都不影响单独的读操作）；

2）线程A进行更新操作，因为更新操作需要加独占锁，而线程B还对当前记录保留了共享锁，故线程A无法获得当前线程的独占锁，要等待线程B释放共享锁；

3）线程B也进行了更新操作，它也要对当前记录加独占锁。那么显然它也无法获得到该记录的独占锁，两个线程都会等待下去，也就是死锁。

4）此时Mysql会自动根据一定规则把锁交给某个线程，另一个线程失去锁重新启动事务。
另外，注意，默认情况下单行执行后就会自动提交事务，此时锁也就被自动释放了。需要关闭事务的自动提交。
set autocommit = 0;

对于需要更新的操作，应当直接使用排他锁。这种情况下，因为线程A已经占有了排他锁，线程B无法获得共享锁和排他锁，只能等待。但是注意，InnoDB的读操作不需要加锁，所以可以照常的读。 当使用SELECT…FOR UPDATE加锁后再更新记录，出现如表20-8所示的情况。 表20-8 InnoDB存储引擎的排他锁例子

三、 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恢复和复制的要求。

到此这篇关于关于Mysql的InnoDB锁概述的文章就介绍到这了,更多相关Mysql的InnoDB锁内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论