[MySQL] gap lock/next-key lock淺析

當InnoDB在判斷行鎖是否衝突的時候, 除了最基本的IS/IX/S/X鎖的衝突判斷意外, InnoDB還將鎖細分爲以下幾種子類型:

• record lock (RK)

  記錄鎖, 僅僅鎖住索引記錄的一行

• gap lock (GK)

  區間鎖, 僅僅鎖住一個區間(開區間)

• insert intention lock (IK)

  意向插入鎖

• next key lock (NK)

  record lock + gap lock, 半開半閉區間, 且下界開, 上界閉

如下鎖兼容矩陣:

request與granted之間的兼容矩陣:

         | Type of active  |
 Request |  lock (granted) |
  lock   | RK   GK  IK  NK |
---------+-----------------+
  RK     |  0   1   1  0   |
  GK     |  1   1   1  1   |
  IK     |  1   0   1  0   |
  NK     |  0   1   1  0   |

---

下面構造集中場景簡單描述下record lock/gap lock/next-key lock

• Table schema

  CREATE TABLE `reno` (
        `id` int(11) NOT NULL AUTO_INCREMENT,
        `name` varchar(10) DEFAULT NULL,
        PRIMARY KEY (`id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

• 構造數據

  insert into reno select 5, 'aa';
    insert into reno select 7, 'bb';
    insert into reno select 9, 'cc';
    insert into reno select 18, 'dd';
    insert into reno select 23, 'ee';
    insert into reno select 30, 'ff';
    insert into reno select 40, 'gg';
    insert into reno select 45, 'hh';
    insert into reno select 99, 'ii';

• 查看結果

  select * from reno;
    +----+------+
    | id | name |
    +----+------+
    |  5 | aa   |
    |  7 | bb   |
    |  9 | cc   |
    | 18 | dd   |
    | 23 | ee   |
    | 30 | ff   |
    | 40 | gg   |
    | 45 | hh   |
    | 99 | ii   |
    +----+------+
    9 rows in set (0.00 sec)

• 查看tx_isolation

  SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
    +-----------------------+----------------+
    | @@GLOBAL.tx_isolation | @@tx_isolation |
    +-----------------------+----------------+
    | READ-COMMITTED        | READ-COMMITTED |
    +-----------------------+----------------+
    1 row in set (0.00 sec)

  next-key lock只有在repeatable-read級別下才有意義, 防止出現幻讀

  設置tx_isolation級別爲REPEATABLE-READ級別:

  SET @@GLOBAL.tx_isolation = 'REPEATABLE-READ';
    Query OK, 0 rows affected (0.00 sec)
  
    SET @@SESSION.tx_isolation = 'REPEATABLE-READ';
    Query OK, 0 rows affected (0.00 sec)
  
    SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
    +-----------------------+-----------------+
    | @@GLOBAL.tx_isolation | @@tx_isolation  |
    +-----------------------+-----------------+
    | REPEATABLE-READ       | REPEATABLE-READ |
    +-----------------------+-----------------+
    1 row in set (0.00 sec)

---

• case 1:

  sesion 1	sesion 2	sesion 2 insert status
  start transaction;
  select * from reno where id = 9 for update;
  	start transaction;
  	insert into reno select 8,'jj';	ok
  	insert into reno select 10,'kk';	ok
  	insert into reno select 3,'ll';	ok
  	insert into reno select 111,'mm';	ok
  	rollback
  rollback

  • 加record lock, id = 9

• case 2:

  sesion 1	sesion 2	sesion 2 insert status
  start transaction;
  select * from reno where id = 15 for update;
  	start transaction;
  	insert into reno select 8, 'jj';	ok
  	insert into reno select 10, 'kk';	block
  	insert into reno select 16, 'll';	block
  	insert into reno select 19, 'mm';	ok
  	rollback
  rollback

  • 加next-key lock, (9, 18]

  • innodb lock info:

    ------------
      TRANSACTIONS
      ------------
      Trx id counter 2990040255
      Purge done for trx's n:o < 2990040253 undo n:o < 0 state: running but idle
      History list length 323
      LIST OF TRANSACTIONS FOR EACH SESSION:
      ---TRANSACTION 0, not started
      MySQL thread id 38753, OS thread handle 0x7f377c68f700, query id 140937 localhost root init
      show engine innodb status
      ---TRANSACTION 0, not started
      MySQL thread id 9, OS thread handle 0x7f370817d700, query id 140906 127.0.0.1 root cleaning up
      ---TRANSACTION 2990040254, ACTIVE 8 sec inserting
      mysql tables in use 1, locked 1
      LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)
      MySQL thread id 38773, OS thread handle 0x7f377c60e700, query id 140924 localhost root executing
      insert into reno select 10, 'kk'
      ------- TRX HAS BEEN WAITING 8 SEC FOR THIS LOCK TO BE GRANTED:
      RECORD LOCKS space id 64257 page no 3 n bits 80 index `PRIMARY` of table `test`.`reno` trx id 2990040254 lock_mode X locks gap before rec insert intention waiting
      Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
       0: len 4; hex 80000012; asc     ;;
       1: len 6; hex 0000b238648b; asc    8d ;;
       2: len 7; hex d70001c00c0110; asc        ;;
       3: len 2; hex 6464; asc dd;;
    
      ------------------
      ---TRANSACTION 2990040253, ACTIVE 17 sec
      2 lock struct(s), heap size 360, 1 row lock(s)
      MySQL thread id 38758, OS thread handle 0x7f370807b700, query id 140919 localhost root cleaning up

    從上面的trx lock信息裏看到此時等待的鎖是: lock_mode X locks gap before rec

• case 3:

  sesion 1	sesion 2	sesion 2 insert status
  start transaction;
  select * from reno where id = 200 for update;
  	start transaction;
  	insert into reno select 1, 'jj';	ok
  	insert into reno select 88, 'kk';	ok
  	insert into reno select 100, 'll';	block
  	insert into reno select 500, 'mm';	block
  	rollback
  rollback

  • 加next-key lock, (99, ~)

  • innodb lock info:

    ------------
      TRANSACTIONS
      ------------
      Trx id counter 2990040257
      Purge done for trx's n:o < 2990040253 undo n:o < 0 state: running but idle
      History list length 323
      LIST OF TRANSACTIONS FOR EACH SESSION:
      ---TRANSACTION 0, not started
      MySQL thread id 38753, OS thread handle 0x7f377c68f700, query id 141561 localhost root init
      show engine innodb status
      ---TRANSACTION 0, not started
      MySQL thread id 9, OS thread handle 0x7f370817d700, query id 141535 127.0.0.1 root cleaning up
      ---TRANSACTION 2990040256, ACTIVE 137 sec inserting
      mysql tables in use 1, locked 1
      LOCK WAIT 2 lock struct(s), heap size 360, 2 row lock(s)
      MySQL thread id 38773, OS thread handle 0x7f377c60e700, query id 141548 localhost root executing
      insert into reno select 500, 'kk'
      ------- TRX HAS BEEN WAITING 10 SEC FOR THIS LOCK TO BE GRANTED:
      RECORD LOCKS space id 64257 page no 3 n bits 80 index `PRIMARY` of table `test`.`reno` trx id 2990040256 lock_mode X insert intention waiting
      Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
      0: len 8; hex 73757072656d756d; asc supremum;;
    
      ------------------
      ---TRANSACTION 2990040255, ACTIVE 153 sec
      2 lock struct(s), heap size 360, 1 row lock(s)
      MySQL thread id 38758, OS thread handle 0x7f370807b700, query id 141432 localhost root cleaning up

    從上面的trx lock信息裏看到此時等待的鎖是: lock_mode X insert intention waiting

簡單總結下:

• 在case 1中, 實際上加的next-key lock是(9,9], 也就是id=9這一條記錄被lock住, 其餘全部的插入都沒有關係.
• 在case 2中, 由於id=15記錄不存在, 且記錄中上下兩個邊界是id=9, id=18, 所以加的next-key lock是(9, 18], 在這個區間內插入的數據都會被block, 此區間外的數據寫入則不受影響.
• 在case 3中, id=200的記錄不存在, 而且比表中全部的記錄都大, 所以innodb則認爲next-key lock是(99, ~), 任何大於99的id記錄插入都會被block, 小於99的id記錄寫入則不受影響.

next-key lock是爲防止幻讀的發生,而只有REPEATABLE-READ以及以上隔離級別才能防止幻讀, 因此在READ-COMMITTED隔離級別下面沒有next-key lock這一說法.

參考:

• https://www.percona.com/blog/2012/03/27/innodbs-gap-locks/
• http://dev.mysql.com/doc/refman/5.1/en/innodb-locks-set.html