1. घर
  2. सवाल और जवाब
  3. MySQL: INSERT से अधिक CPU गहन क्यों हटाया जाता है?

MySQL: INSERT से अधिक CPU गहन क्यों हटाया जाता है?

2011-02-17 23 views
7

मैं वर्तमान में विश्वविद्यालय में "प्रदर्शन मूल्यांकन" पाठ्यक्रम ले रहा हूं, और अब हम एक असाइनमेंट कर रहे हैं जहां हम एक PHP और MySQL-डेटाबेस सर्वर पर CPU उपयोग का परीक्षण कर रहे हैं। हम कस्टम ट्रैफिक बनाने के लिए httperf का उपयोग करते हैं, और सर्वर लोड को ट्रैक करने के लिए vmstat का उपयोग करते हैं। हम PHP-सर्वर के लिए 3000 कनेक्शन चला रहे हैं, दोनों INSERT और DELETE (अलग से चलाएं) के लिए।MySQL: INSERT से अधिक CPU गहन क्यों हटाया जाता है?

संख्याएं दिखाती हैं कि DELETE ऑपरेशन INSERT की तुलना में बहुत अधिक CPU गहन है - और मैं बस सोच रहा हूं क्यों?

मैंने शुरू में सोचा था कि आईएनएसईआरटी को अधिक CPU उपयोग की आवश्यकता है, क्योंकि इंडेक्स को फिर से बनाने की आवश्यकता होगी, डेटा को डिस्क पर लिखा जाना आवश्यक है, लेकिन जाहिर है कि मैं गलत हूं, और मुझे आश्चर्य है कि कोई मुझे तकनीकी बता सकता है इसके लिए कारण

स्रोत

2011-02-17 Trond

+0

स्पष्ट प्रश्न: क्या यह हमेशा * है कि एक डिलीट एक इंसर्ट की तुलना में अधिक संसाधन गहन है, या यह सिर्फ आपका विशिष्ट सेट-अप हो सकता है? यदि यह हमेशा होता है, तो कौन कहता है? – Tomalak

उत्तर

3

DELETE को डिस्क पर डेटा, साथ ही इंडेक्स का पुनर्मूल्यांकन, और इसके अलावा, लॉजिकल तुलनाओं का एक सेट भी रिकॉर्ड करने के लिए आवश्यक है जिसे आप पहले स्थान पर हटाने की कोशिश कर रहे हैं।

स्रोत

2011-02-17 20:04:24 Randy

+2

यह तर्क डेटाबेस में बाधाओं पर बहुत निर्भर करता है, और क्या डेटा डाला जा रहा है, उन बाधाओं से प्रभावित हो सकता है। –

1

हटाएं आपके विचार से अधिक तर्क की आवश्यकता है; स्कीमा की संरचना पर कितना निर्भर करता है।

लगभग सभी मामलों में, जब रिकॉर्ड को हटाते हैं, तो सर्वर को उस रिकॉर्ड पर विदेशी कुंजी संदर्भ के रूप में किसी भी निर्भरता की जांच करनी होगी। संक्षेप में, इस तालिका में एक विदेशी कुंजी रेफरी के साथ तालिका परिभाषाओं की तलाश करने वाले सिस्टम टेबल की एक क्वेरी है, फिर रिकॉर्ड्स को संदर्भित करने के लिए रिकॉर्ड के संदर्भ में उन तालिकाओं में से प्रत्येक का चयन करें। ठीक है, वहां आपने परिमाण के कुछ आदेशों द्वारा कम्प्यूटेशनल समय बढ़ाया है, भले ही सर्वर डिलीट को कैस्केड करता है या सिर्फ एक त्रुटि को फेंक देता है।

स्व-संतुलन आंतरिक डेटा संरचनाओं को पुनर्गठित करना होगा, और सूचकांक पेड़ की किसी भी खाली शाखाओं को हटाने के लिए इंडेक्स को अद्यतन करना होगा, लेकिन इन्हें सम्मिलित संचालन में समकक्ष होंगे।

स्रोत

2011-02-17 20:06:24 KeithS

+1

यदि उस तालिका के लिए कोई विदेशी कुंजी (आउटगोइंग) पंजीकृत नहीं है, तो कोई अतिरिक्त काम नहीं है। यदि कोई विदेशी कुंजी (आने वाली) है, तो डालने के लिए उतना ही काम है। विदेशी कुंजी तर्क पर्याप्त IMHO मजबूत नहीं है। – Tomalak

+1

मैं असहमत हूं। यदि इस तालिका को कहीं और संदर्भित करने वाली कोई विदेशी कुंजी नहीं है, तो आपको रिकॉर्ड को हटाने से पहले sysobjects (या जो कुछ भी) के तालिका स्कैन के साथ सत्यापित करना होगा। ऐसा नहीं करते समय। यदि रिकॉर्ड एक विदेशी तालिका का संदर्भ देता है, तो एक डालने अधिक महंगा है, लेकिन ज्यादा नहीं; आपको संदर्भित तालिका में संदर्भित आईडी के साथ रिकॉर्ड प्राप्त करना होगा। संदर्भित तालिका या तो स्थिर रूप से ज्ञात है या वर्तमान तालिका की परिभाषा को खींचने के लिए sysobjects (et alii) पर लॉग-टाइम खोज के साथ खोज की गई है। संदर्भित आईडी के साथ शून्य या एक रिकॉर्ड ढूँढना लॉग-टाइम भी है। – KeithS

+1

मान लीजिए कि आपको प्रत्येक डिलीट अनुरोध के साथ विदेशी कुंजी के लिए * वास्तविक अलग क्वेरी * के साथ जांच करनी है (जिसे मैं विश्वास करने से इनकार करता हूं, क्योंकि यह संभवतः यह करने के लिए एक स्पष्ट बात है कि उन्होंने संभवतः ऐसा किया है) - आप अभी भी * * हर डालने के लिए वही करना है। यह मानते हुए कि किसी भी दिशा में कोई एफके नहीं है, तो एक डिलीट अर्थात् एक सम्मिलन से अलग नहीं है। एक डालने के लिए भी डिस्क पर लिखे गए वास्तविक बाइट्स की आवश्यकता होती है, यहां तक ​​कि एक सूचकांक भी विभाजित हो सकता है, लेकिन एक डिलीट - इनमें से कोई भी नहीं। * यदि * हटाए जाते हैं तो आम तौर पर धीमे होते हैं (एफके अलग होते हैं), मुझे यकीन है कि क्यों जानना है। – Tomalak

5

कम से कम इनो डीबी के साथ (और मुझे उम्मीद है कि वे इस पर हैं), आपके पास अधिक ऑपरेशन हैं, यहां तक ​​कि कोई विदेशी कुंजी भी नहीं है। द्विआधारी लॉग बफ़र में

  1. पंक्ति सम्मिलित
  2. मार्क
  3. मार्क प्रतिबद्ध

हटाए निम्न करें:: एक डालने मोटे तौर पर यह है

  1. मार्क पंक्ति हटा दिया (लेने एक प्रविष्टि के रूप में एक ही हिट - पृष्ठ फिर से लिखा गया है)
  2. बाइनरी लॉग बफ में चिह्नित करें एर
  3. मार्क प्रतिबद्ध
  4. असल पंक्ति, (एक प्रविष्टि के रूप में ही हिट लेने - पेज पुनः लिखा जाता है) को हटाने जाना
  5. शुद्ध धागा भी द्विआधारी लॉग बफ़र में विलोपन ट्रैक करता है।

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

स्रोत

2011-02-17 20:25:00

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^