A place in an InnoDB index data structure where new values could be inserted.
说白了gap就是索引树中插入新记录的空隙。相应的gap lock就是加在gap上的锁,还有一个next-key锁,是记录+记录前面的gap的组合的锁。
To prevent phantoms, InnoDB uses an algorithm called next-key locking that combines index-row locking with gap locking.
InnoDB performs row-level locking in such a way that when it searches or scans a table index, it sets shared or exclusive
locks on the index records it encounters.Thus, the row-level locks are actually index-record locks. In addition, a next-key
lock on an index record also affects the “gap” before that index record. That is, a next-key lock is an index-record lock
plus a gap lock on the gap preceding the index record. If one session has a shared or exclusive lock on record R in an index,
another session cannot insert a new index record in the gap immediately before R in the index order.
简单讲就是防止幻读。经过锁阻止特定条件的新记录的插入,由于插入时也要获取gap锁(Insert Intention Locks)。html
这和隔离级别有关,只在REPEATABLE READ或以上的隔离级别下的特定操做才会取得gap lock或nextkey lock。mysql
http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.htmlsql
2.1 REPEATABLE READ数据库
... For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read. ... For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), UPDATE, and DELETE statements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it. For other search conditions, InnoDB locks the index range scanned, using gap locks or next-key locks to block insertions by other sessions into the gaps covered by the range.
locking reads,UPDATE和DELETE时,除了对惟一索引的惟一搜索外都会获取gap锁或next-key锁。即锁住其扫描的范围。session
下面对非惟一索引作一个测试:并发
建立表 tb2 ,注意,id 不是主键,是非惟一索引。测试
mysql> CREATE TABLE `tb2` ( -> `id` int(11) DEFAULT NULL, -> `c1` int(11) DEFAULT NULL, -> KEY `tb2_idx1` (`id`) -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
表中有3条记录:spa
mysql> select * from tb2; +------+------+ | id | c1 | +------+------+ | 10 | 0 | | 20 | 0 | | 30 | 0 | +------+------+
开启两个事务 t1 和 t2,rest
在t1中,更新 id=20 的记录code
mysql> update tb2 set c1=2 where id=20; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0
在t2中,执行插入操做,发现[10,30)范围不能插入数据。
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> insert into tb2 values(9,4); Query OK, 1 row affected (0.00 sec) mysql> insert into tb2 values(10,4); ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> insert into tb2 values(19,4); ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> insert into tb2 values(20,4); ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> insert into tb2 values(21,4); ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> insert into tb2 values(29,4); ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> insert into tb2 values(30,4); Query OK, 1 row affected (0.01 sec)
再看看更新操做
mysql> update tb2 set c1=4 where id=10; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> update tb2 set c1=4 where id=20; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> update tb2 set c1=4 where id=30; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0
能够看到,update除了id=20的记录之外,其余的update操做都成功了。
结论:若是 t1 的表扫描没有用到索引,那么gap或next-key锁住的范围是该记录以及该记录先后的gap(包括该记录前一条记录,但不包括后一条记录),这个范围内不能够插入值,但能够更新值(除了被锁住的那条记录)。
For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), UPDATE statements, and DELETE statements, InnoDB locks only index records, not the gaps before them, and thus permits the free insertion of new records next to locked records.
只会锁住已有记录,不会加gap锁。
This level is like REPEATABLE READ, but InnoDB implicitly converts all plain SELECT statements to SELECT ... LOCK IN SHARE MODE if autocommit is disabled.
和REPEATABLE READ的主要区别在于把普通的SELECT变成SELECT ... LOCK IN SHARE MODE,即对普通的select都会获取gap锁或next-key锁。
在“consistent-read”时,REPEATABLE READ下看到是事务开始时的快照,即便其它事务插入了新行一般也是看不到的,因此在常见的场合能够避免幻读。 可是,"locking read"或更新,删除时是会看到已提交的修改的,包括新插入的行。
下面看一个例子
mysql> START TRANSACTION; Query OK, 0 rows affected (0.00 sec) mysql> select id,c1 from tb1 where id=1; +----+------+ | id | c1 | +----+------+ | 1 | 100 | +----+------+ row in set (0.00 sec)
SESSION 2:
mysql> update tb1 set c1=101 where id =1; Query OK, 1 row affected (0.03 sec) Rows matched: 1 Changed: 1 Warnings: 0
SESSION 1:
mysql> select id,c1 from tb1 where id=1 LOCK IN SHARE MODE; +----+------+ | id | c1 | +----+------+ | 1 | 101 | +----+------+ row in set (0.00 sec) mysql> select id,c1 from tb1 where id=1; +----+------+ | id | c1 | +----+------+ | 1 | 100 | +----+------+ row in set (0.00 sec) mysql> update tb1 set c1=c1+1000 where id=1; Query OK, 1 row affected (0.02 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select id,c1 from tb1 where id=1; +----+------+ | id | c1 | +----+------+ | 1 | 1101 | +----+------+ row in set (0.00 sec)
上面update的行为违反了REPEATABLE READ的承诺,看到了事务开始后其它事务的并发更新。这对应用开发须要特别注意,这种状况下其它数据库一般都是报错的。
RR和RC相比还有一个重要的区别,RC下,扫描过但不匹配的记录不会加锁,或者是先加锁再释放,即semi-consistent read。但RR下扫描过记录都要加锁。这个差异对有全表扫描的更新的场景影响极大。详细参考http://hedengcheng.com/?p=771,关于MySQL的加锁处理,这篇文章讲得很透彻!