InnoDB中锁的算法(3)

Ⅰ、隐式锁vs显示锁

session1：

(root@localhost) [test]> show variables like 'tx_isolation';
+---------------+----------------+
| Variable_name | Value          |
+---------------+----------------+
| tx_isolation  | READ-COMMITTED |
+---------------+----------------+
1 row in set (0.00 sec)

(root@localhost) [test]> begin;
Query OK, 0 rows affected (0.00 sec)

(root@localhost) [test]> insert into l values (16,18,20,22);
Query OK, 1 row affected (0.00 sec)

(root@localhost) [test]> show engine innodb status\G
...
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421305875781456, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 31220665, ACTIVE 24 sec
1 lock struct(s), heap size 1136, 0 row lock(s), undo log entries 1
MySQL thread id 1185, OS thread handle 139830020065024, query id 7781 localhost root starting
show engine innodb status
TABLE LOCK table `test`.`l` trx id 31220665 lock mode IX
...

会发现插入的这条记录上没有锁,只能看到一把意向锁

session2：

(root@localhost) [test]> begin;
Query OK, 0 rows affected (0.00 sec)

(root@localhost) [test]> select * from l where a = 16 for update;
hang~~~  ???

session1：

(root@localhost) [test]> show engine innodb status\G
...
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421305875783280, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 31220670, ACTIVE 18 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 1184, OS thread handle 139830453040896, query id 7783 localhost root statistics
select * from l where a = 16 for update
------- TRX HAS BEEN WAITING 18 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1358 page no 3 n bits 80 index PRIMARY of table `test`.`l` trx id 31220670 lock_mode X locks rec but not gap waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 4; hex 80000010; asc     ;;
 1: len 6; hex 000001dc63b9; asc     c ;;
 2: len 7; hex b4000001a10110; asc        ;;
 3: len 4; hex 80000012; asc     ;;
 4: len 4; hex 80000014; asc     ;;
 5: len 4; hex 80000016; asc     ;;

------------------
TABLE LOCK table `test`.`l` trx id 31220670 lock mode IX
RECORD LOCKS space id 1358 page no 3 n bits 80 index PRIMARY of table `test`.`l` trx id 31220670 lock_mode X locks rec but not gap waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 4; hex 80000010; asc     ;;
 1: len 6; hex 000001dc63b9; asc     c ;;
 2: len 7; hex b4000001a10110; asc        ;;
 3: len 4; hex 80000012; asc     ;;
 4: len 4; hex 80000014; asc     ;;
 5: len 4; hex 80000016; asc     ;;

---TRANSACTION 31220665, ACTIVE 252 sec
2 lock struct(s), heap size 1136, 1 row lock(s), undo log entries 1
MySQL thread id 1185, OS thread handle 139830020065024, query id 7781 localhost root
TABLE LOCK table `test`.`l` trx id 31220665 lock mode IX
RECORD LOCKS space id 1358 page no 3 n bits 80 index PRIMARY of table `test`.`l` trx id 31220665 lock_mode X locks rec but not gap
Record lock, heap no 7 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 4; hex 80000010; asc     ;;
 1: len 6; hex 000001dc63b9; asc     c ;;
 2: len 7; hex b4000001a10110; asc        ;;
 3: len 4; hex 80000012; asc     ;;
 4: len 4; hex 80000014; asc     ;;
 5: len 4; hex 80000016; asc     ;;
...

这里可以发现这条记录上的锁又出来了,为什么？

原因：innodb做了优化,这个锁叫隐式锁,这条记录不需要加锁就知道上面有锁,因为这条记录对应的事务还在事务活跃列表中

• 显式锁(explicit-lock)
  
  select * from t where rowd = xxx for update；
• 隐式锁(implicit-lock)
  
  不创建锁对象若没有锁冲突,发生等待则转化为显示锁,这样锁的开销就进一步下降了,几乎很少

小结：

insert操作一开始是隐式锁,不创建锁对象,发生等待的时候才转化为显式锁,查到a=16这条记录在活跃事务列表中,就是没提交,说明上面有锁,这时候创建锁对象,即延迟创建锁对象,如果在延迟过程中,没有对这条记录加锁,就不用创建锁对象,这样就节省内存了

Ⅱ、插入意向锁

session1：

(root@localhost) [test]> show variables like 'tx_isolation';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tx_isolation  | REPEATABLE-READ |
+---------------+-----------------+
1 row in set (0.00 sec)

(root@localhost) [test]> select * from l;
+----+------+------+------+
| a  | b    | c    | d    |
+----+------+------+------+
|  2 |    4 |    6 |    8 |
|  4 |    6 |    8 |   10 |
|  6 |    8 |   10 |   12 |
|  8 |   10 |   12 |   14 |
| 10 |   12 |   14 |   16 |
| 20 |   22 |   24 |   26 |
+----+------+------+------+
6 rows in set (0.00 sec)

(root@localhost) [test]> begin;
Query OK, 0 rows affected (0.00 sec)

(root@localhost) [test]> select * from l where a < 20 for update;
+----+------+------+------+
| a  | b    | c    | d    |
+----+------+------+------+
|  2 |    4 |    6 |    8 |
|  4 |    6 |    8 |   10 |
|  6 |    8 |   10 |   12 |
|  8 |   10 |   12 |   14 |
| 10 |   12 |   14 |   16 |
+----+------+------+------+
5 rows in set (0.00 sec)

session2：

(root@localhost) [test]> begin;
Query OK, 0 rows affected (0.00 sec)

(root@localhost) [test]> insert into l values (14 ,16, 18, 20);
~~~

session3：

(root@localhost) [test]> show engine innodb status\G
...
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421305875783280, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 31220676, ACTIVE 27 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 1184, OS thread handle 139830453040896, query id 7811 localhost root update
insert into l values (14 ,16, 18, 20)
------- TRX HAS BEEN WAITING 27 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1358 page no 3 n bits 80 index PRIMARY of table `test`.`l` trx id 31220676 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 4; hex 80000014; asc     ;;
 1: len 6; hex 000001dc63c1; asc     c ;;
 2: len 7; hex ba000001970110; asc        ;;
 3: len 4; hex 80000016; asc     ;;
 4: len 4; hex 80000018; asc     ;;
 5: len 4; hex 8000001a; asc     ;;

------------------
TABLE LOCK table `test`.`l` trx id 31220676 lock mode IX
RECORD LOCKS space id 1358 page no 3 n bits 80 index PRIMARY of table `test`.`l` trx id 31220676 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 4; hex 80000014; asc     ;;
 1: len 6; hex 000001dc63c1; asc     c ;;
 2: len 7; hex ba000001970110; asc        ;;
 3: len 4; hex 80000016; asc     ;;
 4: len 4; hex 80000018; asc     ;;
 5: len 4; hex 8000001a; asc     ;;

---TRANSACTION 31220675, ACTIVE 75 sec
2 lock struct(s), heap size 1136, 6 row lock(s)
MySQL thread id 1185, OS thread handle 139830020065024, query id 7809 localhost root
TABLE LOCK table `test`.`l` trx id 31220675 lock mode IX
RECORD LOCKS space id 1358 page no 3 n bits 80 index PRIMARY of table `test`.`l` trx id 31220675 lock_mode X
Record lock, heap no 2 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 4; hex 80000002; asc     ;;
 1: len 6; hex 000001c1b939; asc      9;;
 2: len 7; hex e0000001a80110; asc        ;;
 3: len 4; hex 80000004; asc     ;;
 4: len 4; hex 80000006; asc     ;;
 5: len 4; hex 80000008; asc     ;;

篇幅原因省略下面不相关记录锁
...

这时候能看到插入意向锁了

gap before rec insert intention waiting

session1：

(root@localhost) [test]> commit;
Query OK, 0 rows affected (0.01 sec)

(root@localhost) [test]> show engine innodb status\G
...
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421305875783280, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 421305875782368, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 31220677, ACTIVE 17 sec
2 lock struct(s), heap size 1136, 1 row lock(s), undo log entries 1
MySQL thread id 1184, OS thread handle 139830453040896, query id 7815 localhost root
TABLE LOCK table `test`.`l` trx id 31220677 lock mode IX
RECORD LOCKS space id 1358 page no 3 n bits 80 index PRIMARY of table `test`.`l` trx id 31220677 lock_mode X locks gap before rec insert intention
Record lock, heap no 7 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 4; hex 80000014; asc     ;;
 1: len 6; hex 000001dc63c1; asc     c ;;
 2: len 7; hex ba000001970110; asc        ;;
 3: len 4; hex 80000016; asc     ;;
 4: len 4; hex 80000018; asc     ;;
 5: len 4; hex 8000001a; asc     ;;
...

可以看到,对20这条记录加了一个gap锁,但是是insert intention的

睁大眼睛啊

session1：

(root@localhost) [test]> begin;
Query OK, 0 rows affected (0.00 sec)

(root@localhost) [test]> insert into l values (15, 17, 19, 20);
Query OK, 1 row affected (0.00 sec)

哦嚯,插入成功,美鸡鸡

Ⅲ、捋一下为什么可以插？

a列：2 4 6 8 10 20

step1：

20这条记录上有一个X锁,next-key-locking,锁住xxx...(10,20]这几个范围

step2：

插入14这条记录,会对20这条记录加一个gap锁,即(14,20),但是这个gap锁有个insert intention的属性

step3：

第一个事务commit,事务2持有了上面这把(14,20)的insert intention的gap锁

这时候插15是能插入的,就因为insert intention

gap锁是用来阻塞的,之前的理解(14,20)之间是不能插入15的,但是有了上面说的这个特性,就表示插入非阻塞,即允许插入,意义在于提升了插入性能

如果没有insert intention,那插入14时(14,20)上面就是加一个gap锁,事务1提交则事务2获取这个gap锁,插入15,是插不了的,性能下降了

tips：

插入14地时候为什么这里会阻塞呢？因为14要在20上加一个gap锁,为什么要加gap锁来判断到底能不能插,一条记录能不能插就看它后面这条记录上有没有锁,这个锁是不是gap的,如果是那就不能插,只是一个record锁那就能插,而这个例子20这条记录上本身是有gap的所以就等待了

总结：

• insert intention用来判断当前事务能否插入,并不阻塞后面其他线程在这个范围的插入操作,提升了并发插入的性能
• gap insert intention互相之间本身是兼容的
• insert在等待的时候(被阻塞)才会加gap insert intention锁,不等待是没任何锁的
• rc没有next-key-lock锁,没有上面的情况,锁住20表示只锁住记录本身,没有锁住一个范围,14是可以直接插的