MySQL InnoDB Deadlock Pour 2 requêtes d'insertion simples


10

J'ai un blocage pour ces deux requêtes d'insertion:

insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.596', 180, 4, 181, 561)

insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.611', 180, 4, 181, 563)

Voici le statut InnoDB:

------------------------
LATEST DETECTED DEADLOCK
------------------------
2014-12-23 15:47:11 1f4c
*** (1) TRANSACTION:
TRANSACTION 19896526, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1248, 3 row lock(s), undo log entries 1
MySQL thread id 17988, OS thread handle 0x17bc, query id 5701353 localhost 127.0.0.1 root update
insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition,  nextClubId, account_id) values (0, '2014-12-23 15:47:11.596', 180, 4, 181, 561)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 49735 page no 4 n bits 72 index `UK_cagoa3q409gsukj51ltiokjoh` of   table `db`.`playerclub` trx id 19896526 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;;

*** (2) TRANSACTION:
TRANSACTION 19896542, ACTIVE 0 sec inserting, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1248, 3 row lock(s), undo log entries 1
MySQL thread id 17979, OS thread handle 0x1f4c, query id 5701360 localhost 127.0.0.1    root update
insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition,   nextClubId, account_id) values (0, '2014-12-23 15:47:11.611', 180, 4, 181, 563)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 49735 page no 4 n bits 72 index `UK_cagoa3q409gsukj51ltiokjoh` of   table `db`.`playerclub` trx id 19896542 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 49735 page no 4 n bits 72 index `UK_cagoa3q409gsukj51ltiokjoh` of    table `db`.`playerclub` trx id 19896542 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;;

*** WE ROLL BACK TRANSACTION (2)

La seule clé foriegn sur cette table est "account_id".

Des idées?

EDIT: Voici mes informations PlayerClub:

CREATE TABLE `PlayerClub` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `modifiedBy` bigint(20) DEFAULT NULL,
  `timeCreated` datetime NOT NULL,
  `account_id` bigint(20) DEFAULT NULL,
  `currentClubId` bigint(20) DEFAULT NULL,
  `endingLevelPosition` int(11) NOT NULL,
  `nextClubId` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UK_cagoa3q409gsukj51ltiokjoh` (`account_id`),
  KEY `FK_cagoa3q409gsukj51ltiokjoh` (`account_id`),
  CONSTRAINT `FK_cagoa3q409gsukj51ltiokjoh` FOREIGN KEY (`account_id`) REFERENCES   `PlayerAccount` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=latin1

Qu'avez-vous fait d'autre dans chaque transaction avant de sortir de l'impasse?
Michael - sqlbot

que faire si vous émettez un commit après chaque insertion et essayez ensuite? Faites-nous savoir ..
Nawaz Sohail

SHOW CREATE TABLE PlayerClubS'il vous plaît. Ceci est généralement lié aux index.
Jehad Keriaki

Réponses:


13

VOICI LES FAITS

Voici les deux INSERT

insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.596', 180, 4, 181, 561)
insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.611', 180, 4, 181, 563)

Voici les deux lignes de votre SHOW ENGINE INNODB STATUS\G

RECORD LOCKS space id 49735 page no 4 n bits 72 index `UK_cagoa3q409gsukj51ltiokjoh` of   table `db`.`playerclub` trx id 19896526 lock_mode X insert intention waiting
RECORD LOCKS space id 49735 page no 4 n bits 72 index `UK_cagoa3q409gsukj51ltiokjoh` of   table `db`.`playerclub` trx id 19896542 lock_mode X

OBSERVATIONS

Vous faites un INSERT avec deux account_ids différents: 561 et 563.

Ils sont uniques et ne devraient pas avoir de problèmes, non? FAUX !!!

En raison de l'index cluster d'InnoDB, il peut toujours y avoir un blocage. Pourquoi ?

Regardez vos deux INSERT. L' PRIMARY KEYidentifiant on n'est pas spécifié. Il doit être généré automatiquement. Toute clé autre que la CLÉ PRIMAIRE (unique ou non unique) aura la CLÉ PRIMAIRE attachée.

Veuillez noter la documentation MySQL sur la façon dont un index secondaire et une clé primaire sont entrelacés :

Tous les index autres que l'index cluster sont appelés index secondaires. Dans InnoDB, chaque enregistrement d'un index secondaire contient les colonnes de clé primaire de la ligne, ainsi que les colonnes spécifiées pour l'index secondaire. InnoDB utilise cette valeur de clé primaire pour rechercher la ligne dans l'index clusterisé.

Si la clé primaire est longue, les index secondaires utilisent plus d'espace, il est donc avantageux d'avoir une clé primaire courte.

Bien que vous insériez account_id 561 et 563, sous le capot, vous insérez 561-(id)et 563-(id)dans l' UK_cagoa3q409gsukj51ltiokjohindex. Le PRIMARY KEYdevient le goulot d'étranglement car l'index secondaire doit attendre que la idcolonne soit générée automatiquement.

RECOMMANDATION

Vous avez une table avec deux clés candidates

  • PRIMARY KEY sur id
  • UNIQUE KEY sur UK_cagoa3q409gsukj51ltiokjoh

Étant donné que les deux le sont BIGINT, vous pouvez augmenter les performances et avoir une PlayerClubtable plus petite en vous débarrassant idet en conservant l'unicité en raison UK_cagoa3q409gsukj51ltiokjohet en évitant cette situation de blocage.


1
Ce n'est qu'après la suppression La seule clé foriegn sur cette table est le "account_id" l'arrêt de blocage se produisant.
Urbanleg
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.