कुछ और पढ़ने के बाद मैंने पाया कि, जैसा कि InnoDB पंक्ति-स्तरीय लॉकिंग का उपयोग करता है, गतिरोध तब हो सकता है जब केवल एक पंक्ति को सम्मिलित या अद्यतन किया जाता है क्योंकि क्रियाएं परमाणु नहीं होती हैं। मैं भागा:
SHOW ENGINE INNODB STATUS
अंतिम गतिरोध के बारे में जानकारी प्राप्त करने के लिए। मैंने पाया:
------------------------
LATEST DETECTED DEADLOCK
------------------------
140106 17:22:41
*** (1) TRANSACTION:
TRANSACTION 63EB5222A, ACTIVE 0 sec starting index read
mysql tables in use 3, locked 3
LOCK WAIT 9 lock struct(s), heap size 3112, 6 row lock(s), undo log entries 2
MySQL thread id 4304350, OS thread handle 0x7fd3b74d3700, query id 173460207 192.168.0.2 sharecash Updating
UPDATE `click_rollups` SET `clicks` = `clicks` + 1, `last_updated` = '1389046961' WHERE `camp_id` = '27739' AND `country` = 'US' AND `clicks` < '1000' AND `time_created` = '1389046866'
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 186 page no 407 n bits 1272 index `country` of table `sharecash`.`click_rollups` trx id 63EB5222A lock_mode X waiting
*** (2) TRANSACTION:
TRANSACTION 63EB52225, ACTIVE 0 sec fetching rows
mysql tables in use 3, locked 3
177 lock struct(s), heap size 31160, 17786 row lock(s), undo log entries 2
MySQL thread id 4304349, OS thread handle 0x7fd6961c8700, query id 173460194 192.168.0.1 sharecash Updating
UPDATE `click_rollups` SET `clicks` = `clicks` + 1, `last_updated` = '1389046961' WHERE `camp_id` = '30949' AND `country` = 'US' AND `clicks` < '1000' AND `time_created` = '1388964767'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 186 page no 407 n bits 1272 index `country` of table `sharecash`.`click_rollups` trx id 63EB52225 lock_mode X
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 186 page no 512 n bits 384 index `PRIMARY` of table `sharecash`.`click_rollups` trx id 63EB52225 lock_mode X locks rec but not gap waiting
*** WE ROLL BACK TRANSACTION (1)
आप देख सकते हैं कि गतिरोध पैदा करने वाले दो प्रश्न वास्तव में वही सटीक हैं। यह दर्शाता है कि WHERE क्लॉज में कॉलम के लिए अलग-अलग पैरामीटर भी हैं, इसलिए लॉक की जा रही वास्तविक पंक्तियाँ अलग हैं, जो मुझे थोड़ी उलटी लग रही थीं - पंक्तियों के विभिन्न सेटों पर संचालन गतिरोध का कारण कैसे बन सकता है?
इसका उत्तर यह प्रतीत होता है कि अनुक्रमण संरचनाओं में क्वेरी इंजन लॉकिंग प्रविष्टियों से गतिरोध उत्पन्न हो रहा है। यदि आप ऊपर दिए गए आउटपुट को देखते हैं, तो आप देख सकते हैं कि country में एक लेन-देन में एक निश्चित पृष्ठ के एक निश्चित भाग पर लॉक है इंडेक्स और प्राथमिक कुंजी इंडेक्स के हिस्से पर लॉक की जरूरत है, जबकि अन्य लेनदेन अनिवार्य रूप से विपरीत मामला है।
हमारे ऐप के इस हिस्से में एक अपरिवर्तनीय है कि केवल एक पंक्ति में कभी भी 1000 से कम क्लिक होंगे, इसलिए मेरा मानना है कि उस मुद्दे को ठीक करने से गतिरोध की समस्या कम हो जाएगी, क्योंकि कुल मिलाकर कम लॉकिंग होगी। MySQL प्रलेखन एक गतिरोध के कारण रोलबैक के मामले में लेनदेन को हमेशा फिर से जारी करने के लिए आपके एप्लिकेशन को कोड करने का सुझाव देता है, जो इस समस्या को पृष्ठों में त्रुटि के कारण रोक देगा। हालांकि, अगर किसी के पास वास्तव में इन गतिरोधों से बचने के बारे में कोई अन्य विचार है, तो कृपया उन्हें टिप्पणियों में पोस्ट करें!
संपादित करें -
country प्रत्येक camp_id . के रूप में, लेन-देन द्वारा अनुक्रमणिका का उपयोग करने की आवश्यकता नहीं थी मान वहाँ केवल कुछ मुट्ठी भर (आमतौर पर सिर्फ 1) country के अलग-अलग मान थे , जिनमें से प्रत्येक केवल एक पंक्ति के अनुरूप है। मैंने इस इंडेक्स का उपयोग बंद करने के लिए क्वेरी में एक इंडेक्स संकेत जोड़ा है, और समस्या अब बिना किसी प्रदर्शन हिट (शायद एक छोटा लाभ) के ठीक हो गई है।
