MySQL InnoDB डेडलॉक 2 सरल सम्मिलित प्रश्नों के लिए


10

मेरे पास इस दो सम्मिलित प्रश्नों के लिए एक गतिरोध है:

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)

यहाँ 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)

इस तालिका में एकमात्र foriegn कुंजी "account_id" है।

कोई विचार?

संपादित करें: यहाँ मेरा खिलाड़ी जानकारी है:

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

डेडलॉक मारने से पहले आपने प्रत्येक लेनदेन में और क्या किया?
माइकल - साइक्लोबॉट

क्या होगा अगर आप प्रत्येक डालने के बाद कमिट करते हैं और फिर कोशिश करते हैं? आइए जानते हैं ..
नवाज़ सोहेल

SHOW CREATE TABLE PlayerClubकृप्या। यह आमतौर पर अनुक्रमित से संबंधित है।
जेहाद केरकीकी

जवाबों:


13

यहाँ तथ्य हैं

यहाँ दो 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)

यहाँ आपके दो लाइन हैं 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

टिप्पणियों

आप दो अलग-अलग account_ids के साथ एक INSERT कर रहे हैं: 561 और 563।

वे अद्वितीय हैं और मुद्दों को नहीं होना चाहिए, है ना? गलत !!!

InnoDB के क्लस्टर इंडेक्स के कारण अभी भी गतिरोध हो सकता है। क्यों ?

अपने दो INSERT को देखें। PRIMARY KEYपर आईडी निर्दिष्ट नहीं में। यह ऑटो जनरेट होना चाहिए। PRIMARY KEY (यूनिक या नॉन-यूनिक) के अलावा कोई भी कुंजी PRIMARY KEY से जुड़ी होगी।

कृपया ध्यान दें कि कैसे एक द्वितीयक सूचकांक और एक प्राथमिक कुंजी intertwined हैं पर MySQL प्रलेखन :

क्लस्टर इंडेक्स के अलावा अन्य सभी इंडेक्स को सेकेंडरी इंडेक्स के रूप में जाना जाता है। InnoDB में, एक माध्यमिक सूचकांक में प्रत्येक रिकॉर्ड में पंक्ति के लिए प्राथमिक कुंजी कॉलम होता है, साथ ही द्वितीयक सूचकांक के लिए निर्दिष्ट कॉलम होते हैं। InnoDB क्लस्टर सूची में पंक्ति की खोज के लिए इस प्राथमिक कुंजी मूल्य का उपयोग करता है।

यदि प्राथमिक कुंजी लंबी है, तो द्वितीयक सूचकांक अधिक स्थान का उपयोग करते हैं, इसलिए छोटी प्राथमिक कुंजी रखना लाभप्रद है।

यद्यपि आप ACCOUNT_ID 561 और 563 डालने कर रहे हैं, हुड आप डालने हैं के तहत 561-(id)और 563-(id)में UK_cagoa3q409gsukj51ltiokjohसूचकांक। PRIMARY KEYटोंटी हो जाता है जब तक क्योंकि माध्यमिक सूचकांक इंतजार करना पड़ता है idस्तंभ auto_generated है।

सिफ़ारिश करना

आपके पास दो उम्मीदवार कुंजी के साथ एक तालिका है

  • PRIMARY KEY पर id
  • UNIQUE KEY पर UK_cagoa3q409gsukj51ltiokjoh

चूंकि दोनों हैं BIGINT, आप प्रदर्शन को बढ़ा सकते हैं और PlayerClubछुटकारा पाकर एक छोटी सी मेज idरख सकते हैं और फिर भी UK_cagoa3q409gsukj51ltiokjohइस अनलॉक स्थिति से बचने के कारण विशिष्टता बनाए रख सकते हैं ।


1
इस तालिका पर एकमात्र foriegn कुंजी को हटाने के बाद ही डेडलॉक स्टॉप "account_id" होता है।
शहरी काल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.