Innodb Update Lock Order On Первичный ключ и вторичный индекс

Question

Когда я изучаю тупик, вызванный двумя запросами обновления. есть какой-то момент, я не могу понять. 1. порядок настройки блокировки строк? 2. порядок установки блокировки на первичный и вторичный индексы при выполнении обновления? 3. SHOW INNODB STATUS show WAITING x lock structs, требуется ли в то же время или требуется один после другого предоставленного? 4. Если одна блокировка struct хочет заблокировать несколько строк, является ли процесс атомом?

вот мой тупиковый: Таблица:

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 Query 1:

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

Update Query 2:

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

Некоторые строки в БД ExampleRows

Ключ сценария:

1. Update По индексу nu_key
2. два запроса обновления разные строки, но две строки имеют одинаковый индекс nu_key
3. TRX1 ЗАМОК WAIT 5 стопорное-структуру (ы)? все блокировки требуют добавления к блокировке графика
4. TRX2 HOLDS PrimaryKey, и блокировка ожидания по индексу nu_key. но в соответствии с тем, что я знаю, блокировка индекса установлена ​​в первую очередь, это требование блокировки не является атомарным? Уровень
5. Изоляция: RR

ТУПИК SHOW STATUS 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 ЗАМОК и RECORD LOCK. GDB dubug исходный код mysql может узнать, MySQL Внутренний DOC имеет несколько KeyPoint, но потерял некоторые детали.