Bug #94087 Two updates with PRIMARY cause a deadlock
Submitted: 28 Jan 2019 5:33 Modified: 28 Jan 2019 14:15
Reporter: he karl Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.7.22 OS:Linux (CentOS release 6.10 (Final))
Assigned to: CPU Architecture:x86
Tags: deadlock

[28 Jan 2019 5:33] he karl
Description:
------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-01-28 00:03:36 0x7f23e8590700
*** (1) TRANSACTION:
TRANSACTION 4669268176, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 10 lock struct(s), heap size 1136, 12 row lock(s), undo log entries 27
MySQL thread id 128470136, OS thread handle 139790916761344, query id 63847167445 10.11.108.124 u_oms4_im updating
update inv_channel_sale_75 c set c.version = c.version + 1, c.last_modify_time = sysdate(), c.qty = c.qty + 1
				where c.id = 736
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 12709 page no 12 n bits 240 index PRIMARY of table `db_oms4_im`.`inv_channel_sale_75` trx id 4669268176 lock_mode X locks rec but not gap waiting
Record lock, heap no 149 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
 0: len 8; hex 80000000000002e0; asc         ;;
 1: len 6; hex 0001164f60cf; asc    O` ;;
 2: len 7; hex 760003b50d014b; asc v     K;;
 3: len 8; hex 8000000000004ddc; asc       M ;;
 4: len 11; hex 4e495645415f426f64616f; asc NIVEA_Bodao;;
 5: len 7; hex 4e495645414b47; asc NIVEAKG;;
 6: len 7; hex 53485748333339; asc SHWH339;;
 7: len 3; hex 393939; asc 999;;
 8: len 9; hex 4e4956454130303331; asc NIVEA0031;;
 9: len 8; hex 80000000000030c3; asc       0 ;;
 10: len 5; hex 99a23800e4; asc   8  ;;

*** (2) TRANSACTION:
TRANSACTION 4669268175, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
9 lock struct(s), heap size 1136, 6 row lock(s), undo log entries 23
MySQL thread id 128469999, OS thread handle 139792198731520, query id 63847167495 10.11.108.124 u_oms4_im updating
update inv_channel_sale_75 c set c.version = c.version + 1, c.last_modify_time = sysdate(), c.qty = c.qty + -1
				where c.id = 85
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 12709 page no 12 n bits 240 index PRIMARY of table `db_oms4_im`.`inv_channel_sale_75` trx id 4669268175 lock_mode X locks rec but not gap
Record lock, heap no 149 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
 0: len 8; hex 80000000000002e0; asc         ;;
 1: len 6; hex 0001164f60cf; asc    O` ;;
 2: len 7; hex 760003b50d014b; asc v     K;;
 3: len 8; hex 8000000000004ddc; asc       M ;;
 4: len 11; hex 4e495645415f426f64616f; asc NIVEA_Bodao;;
 5: len 7; hex 4e495645414b47; asc NIVEAKG;;
 6: len 7; hex 53485748333339; asc SHWH339;;
 7: len 3; hex 393939; asc 999;;
 8: len 9; hex 4e4956454130303331; asc NIVEA0031;;
 9: len 8; hex 80000000000030c3; asc       0 ;;
 10: len 5; hex 99a23800e4; asc   8  ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 12709 page no 6 n bits 240 index PRIMARY of table `db_oms4_im`.`inv_channel_sale_75` trx id 4669268175 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
 0: len 8; hex 8000000000000055; asc        U;;
 1: len 6; hex 0001164f60d0; asc    O` ;;
 2: len 7; hex 770006596a1d78; asc w  Yj x;;
 3: len 8; hex 800000000003e730; asc        0;;
 4: len 11; hex 4e495645415f426f64616f; asc NIVEA_Bodao;;
 5: len 7; hex 4e495645414b47; asc NIVEAKG;;
 6: len 7; hex 53485748333339; asc SHWH339;;
 7: len 3; hex 393939; asc 999;;
 8: len 9; hex 4e4956454130313436; asc NIVEA0146;;
 9: len 8; hex 8000000000003d86; asc       = ;;
 10: len 5; hex 99a23800e4; asc   8  ;;

How to repeat:
Two updates with  PRIMARY cause a deadlock
[28 Jan 2019 14:15] MySQL Verification Team
Hi,

Deadlocks are a normal occurrence in all transactional storage engines. The fact that you get a deadlock error from the InnoDB storage engine, means that there is no bug. It actually means that storage engine is functioning perfectly.

InnoDB goes in fact far beyond that. It uses theory of graphs to find as many transactions involved in the deadlock as possible. Deadlock detection is also, practically instantaneous. 

All you have to do is to search for that error when return from some SQL statement and re-commit the entire transaction.

This is all fully explained in our Reference Manual.