Innodb更新主键和二级索引的锁定顺序

时间:2016-06-30 07:48:14

标签: mysql innodb rowlocking

当我研究由两个更新查询引起的死锁时。有一点,我无法理解。 1.行锁设置的顺序? 2.更新执行时,主索引和辅助索引的锁定设置顺序? 3.显示INNODB状态显示等待x锁定结构,是否需要同时或在其他授权后需要一个? 4.如果一个锁结构想要锁定一些行,那么进程是原子的吗?

这是我的僵局: 表:

CREATE TABLE `study_update_deadlock` (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `u_key` bigint(20) DEFAULT NULL,
    `nu_key` bigint(20) DEFAULT NULL,
    `version` int(11) DEFAULT NULL,
    `quantity` int(11) DEFAULT NULL,
    PRIMARY KEY (`id`),
    KEY `nu_key` (`nu_key`),
    KEY `u_key` (`u_key`)
) ENGINE=InnoDB AUTO_INCREMENT=5000001 DEFAULT CHARSET=latin1 COMMENT='根据非唯一主键更新是发生死锁'

更新查询1:

update study_update_deadlock set version=version+1 where u_key=1663577608119220637 and nu_key=12498159

更新查询2:

update study_update_deadlock set quantity=quantity+1 where u_key=1470344318505049187 and nu_key=12498159

DB中的某些行 ExampleRows

方案的关键:

  1. 根据nu_key索引更新
  2. 两个查询更新不同的行但两行具有相同的nu_key索引
  3. TRX1 LOCK WAIT 5锁定结构?将所有锁定需要添加到锁定图表
  4. TRX2 HOLDS PrimaryKey,并等待nu_key索引锁定。但根据我所知道的索引锁定首先是锁定需求是不是原子?
  5. 隔离级别:RR
  6. DeadLock SHOW INNODB STATUS

    2016-06-29 18:58:32 700001f3b000
    *** (1) TRANSACTION:
    TRANSACTION 76027, ACTIVE 0 sec fetching rows
    mysql tables in use 3, locked 3
    LOCK WAIT 5 lock struct(s), heap size 1184, 8 row lock(s)
    MySQL thread id 33311, OS thread handle 0x700001ab7000, query id 204129 localhost root updating
    update study_update_deadlock set quantity = quantity+1 where u_key= 1470344318505049187 and nu_key=12498159
    *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
    RECORD LOCKS space id 16 page no 22255 n bits 392 index `PRIMARY` of table `test`.`study_update_deadlock` trx id 76027 lock_mode X locks rec but not gap waiting
    Record lock, heap no 255 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
     0: len 4; hex 8036731e; asc  6s ;;
     1: len 6; hex 0000000128fa; asc     ( ;;
     2: len 7; hex 770000179e081e; asc w      ;;
     3: len 8; hex 97163705443d799d; asc   7 D=y ;;
     4: len 8; hex 8000000000beb4ef; asc         ;;
     5: len 4; hex 800000bb; asc     ;;
     6: len 4; hex 8000005a; asc    Z;;
    
    *** (2) TRANSACTION:
    TRANSACTION 76028, ACTIVE 0 sec starting index read
    mysql tables in use 3, locked 3
    4 lock struct(s), heap size 1184, 3 row lock(s)
    MySQL thread id 33312, OS thread handle 0x700001f3b000, query id 204130 localhost root updating
    update study_update_deadlock set version = version+1 where u_key= 1663577608119220637 and nu_key=12498159
    *** (2) HOLDS THE LOCK(S):
    RECORD LOCKS space id 16 page no 22255 n bits 392 index `PRIMARY` of table `test`.`study_update_deadlock` trx id 76028 lock_mode X locks rec but not gap
    Record lock, heap no 255 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
     0: len 4; hex 8036731e; asc  6s ;;
     1: len 6; hex 0000000128fa; asc     ( ;;
     2: len 7; hex 770000179e081e; asc w      ;;
     3: len 8; hex 97163705443d799d; asc   7 D=y ;;
     4: len 8; hex 8000000000beb4ef; asc         ;;
     5: len 4; hex 800000bb; asc     ;;
     6: len 4; hex 8000005a; asc    Z;;
    
    *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
    RECORD LOCKS space id 16 page no 22336 n bits 952 index `nu_key` of table `test`.`study_update_deadlock` trx id 76028 lock_mode X waiting
    Record lock, heap no 660 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
     0: len 8; hex 8000000000beb4ef; asc         ;;
     1: len 4; hex 8036731c; asc  6s ;;
    
    *** WE ROLL BACK TRANSACTION (2)
    

1 个答案:

答案 0 :(得分:0)

这是因为GAP LOCK和RECORD LOCK。 GDB的dubug mysql源代码可以看出来,MySQL内部DOC有一些KeyPoint但是丢失了一些细节。