Innodb 기본 키 및 보조 인덱스에서 잠금 주문

Question

두 개의 업데이트 쿼리로 인해 교착 상태가 발생하는 경우를 연구합니다. 나는 이해할 수 없다. 1. 행 잠금 설정 순서? 2. 업데이트가 실행될 때 1 차 및 2 차 인덱스에서 잠금 설정 순서? 3. SHOW INNODB STATUS는 x lock struct를 기다리는 것을 보여줍니다. 동시에 필요합니까? 아니면 다른 것이 부여 된 후에 하나가 필요합니까? 4. 하나의 잠금 구조체가 일부 행을 잠 그려면 프로세스가 어 떻지 않은가? DB에서 ExampleRows

012,351

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

일부 행 : 쿼리 1

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='根据非唯一主键更新是发生死锁' 

업데이트 :

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

업데이트 쿼리 2 테이블 : 여기

내 교착 상태입니다 시나리오의 6,

키 :

1. 업데이트가 nu_key 지수
2. 이 쿼리 업데이트 다른 행하지만 두 행을 따르면 같은 nu_key 지수를
3. TRX1의 LOCK WAIT 5 잠금 구조체 (들)을 가지고? 모두 잠금 요구 그래프를 잠그기 위해 추가되었습니다.
4. TRX2 HOLDS PrimaryKey 및 nu_key 인덱스에서 대기 잠금. 하지만 인덱스 잠금을 먼저 알고있는 것에 따라 자물쇠는 원자가 아닌가?
5. 격리 수준 : RR

교착 쇼 INNODB 상태

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) 

Answer 1

GAP LOCK 및 녹화 잠금이 원인. MySQL의 GDB dubug 소스 코드를 보면 MySQL 내부 DOC가 KeyPoint를 가지고 있지만 세부 사항을 잃어 버렸습니다.