MySQL डेटाबेस अनुकूलन सर्वोत्तम प्रथाओं

Question

कुछ बड़े टेबल (> प्रति तालिका लगभग 100 एमबी के साथ 50k रिकॉर्ड) को संभालने के दौरान सर्वोत्तम प्रदर्शन के लिए MySQL स्थापना को अनुकूलित करने के लिए सर्वोत्तम प्रथाओं क्या हैं? वर्तमान में हम DelphiFeeds.com (डेल्फी प्रोग्रामिंग समुदाय के लिए एक समाचार साइट) को फिर से लिखने की तलाश में हैं और ध्यान दिया है कि सरल अद्यतन विवरणों में 50ms तक का समय लग सकता है। यह बहुत पसंद है। क्या कोई अनुशंसित कॉन्फ़िगरेशन सेटिंग्स हैं जिन्हें हमें सक्षम/सेट करना चाहिए जो आम तौर पर एक मानक MySQL स्थापना पर अक्षम होते हैं (उदाहरण के लिए क्वेरी और डेटा कैश करने के लिए अधिक रैम का लाभ उठाने के लिए)?

इसके अलावा, स्टोरेज इंजनों की पसंद के प्रदर्शन के प्रभाव क्या हैं? हम इनो डीबी के साथ जाने की योजना बना रहे हैं, लेकिन यदि प्रदर्शन कारणों से माईसाम की सिफारिश की जाती है, तो हम माईसाम का उपयोग कर सकते हैं।

Answer 1

"सबसे अच्छा अभ्यास" है:

1. प्रदर्शन का आकलन करें, प्रासंगिक सबसिस्टम अलग रूप में अच्छी तरह आप कर सकते हैं के रूप में।
2. बाधा के मूल कारण की पहचान करें। क्या आप I/O बंधे हैं? सीपीयू बाध्य? मेमोरी बाध्य? ताले पर इंतजार कर रहे हैं?
3. आपके द्वारा खोजे गए मूल कारण को कम करने के लिए परिवर्तन करें।
4. फिर से मापें, यह दिखाने के लिए कि आपने बाधा और कितनी तय की है।
5. चरण 2 पर जाएं और जब तक सिस्टम पर्याप्त तेज़ी से काम न करे तब तक दोहराएं।

http://www.mysqlperformanceblog.com पर आरएसएस फ़ीड की सदस्यता लें और इसके ऐतिहासिक लेख भी पढ़ें। यह प्रदर्शन से संबंधित ज्ञान के लिए एक बेहद उपयोगी संसाधन है। उदाहरण के लिए, आपने InnoDB बनाम MyISAM के बारे में पूछा। उनके निष्कर्ष: InnoDB औसत पर MyISAM की तुलना में ~ 30% उच्च प्रदर्शन है। यद्यपि कुछ उपयोग परिदृश्य भी हैं जहां MyISAM InnoDB निष्पादित करता है।

• InnoDB vs. MyISAM vs. Falcon benchmarks - part 1

कि ब्लॉग के लेखक भी "उच्च प्रदर्शन MySQL," पुस्तक @Andrew बार्नेट ने उल्लेख के सह-लेखक हैं। @ से

---

पुन टिप्पणी ʞɔıu: कैसे पता करें कि कि क्या आप आई/ओ बाध्य स्मृति बनाम बाध्य सीपीयू बनाम बाध्य कर रहे हैं मंच पर निर्भर है। ऑपरेटिंग सिस्टम ps, iostat, vmstat, या शीर्ष जैसे टूल पेश कर सकता है। या यदि आपका ओएस एक प्रदान नहीं करता है तो आपको एक थर्ड-पार्टी टूल प्राप्त करना पड़ सकता है।

असल में, जो भी संसाधन 100% उपयोग/संतृप्ति पर आच्छादित है, वह आपकी बाधा बनने की संभावना है। यदि आपका सीपीयू लोड कम है लेकिन आपका I/O लोड आपके हार्डवेयर के लिए अधिकतम है, तो आप I/O बाध्य हैं।

हालांकि, यह केवल एक डेटा बिंदु है। उपचार अन्य कारकों पर भी निर्भर हो सकता है। उदाहरण के लिए, एक जटिल SQL क्वेरी एक फाइलोर्ट कर रही है, और यह I/O व्यस्त रखती है। क्या आपको उस पर अधिक तेज़ हार्डवेयर फेंकना चाहिए, या क्या आपको फाइलोर्ट से बचने के लिए क्वेरी को फिर से डिजाइन करना चाहिए?

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

---

जेफ Atwood सिर्फ एक प्रणाली में बाधाओं खोजने के बारे में एक अच्छा ब्लॉग लेख लिखा था:

• The Computer Performance Shell Game

Answer 2

ओ'रेली से "उच्च प्रदर्शन MySQL" खरीदें। इस विषय पर लगभग 700 पेज हैं, इसलिए मुझे संदेह है कि आपको SO पर एक संक्षिप्त उत्तर मिलेगा।

Answer 3

यह चीजें broadbrush करना मुश्किल है, लेकिन एक मामूली उच्च-स्तरीय दृश्य संभव है ।

• आपको पढ़ने का मूल्यांकन करने की आवश्यकता है: अनुपात लिखें। लगभग 5: 1 से कम अनुपात वाले तालिकाओं के लिए, आपको शायद इनो डीबी से लाभ होगा क्योंकि तब आवेषण चयन को अवरुद्ध नहीं करेंगे। लेकिन यदि आप लेनदेन का उपयोग नहीं कर रहे हैं, तो आपको MyISAM पर प्रदर्शन प्राप्त करने के लिए innodb_flush_log_at_trx_commit से 1 बदलना चाहिए।
• मेमोरी पैरामीटर देखें। MySQL के डिफ़ॉल्ट बहुत रूढ़िवादी हैं और कुछ हार्डवेयर सीमाओं को सामान्य हार्डवेयर पर 10 या उससे अधिक के कारक द्वारा उठाया जा सकता है। यह INSERT के बजाय आपके SELECT को लाभान्वित करेगा।
• MySQL उन प्रश्नों जैसे लॉग इन कर सकता है जो इंडेक्स का उपयोग नहीं कर रहे हैं, साथ ही ऐसे प्रश्न जो केवल बहुत लंबे समय तक (उपयोगकर्ता परिभाषित करने योग्य) लेते हैं।
• क्वेरी कैश उपयोगी हो सकता है, लेकिन आपको इसे वाद्य यंत्र की आवश्यकता है (यानी देखें कि इसका कितना उपयोग किया जाता है)। कैक्टि ऐसा कर सकता है; मुनिन के रूप में कर सकते हैं।
• आवेदन डिजाइन भी महत्वपूर्ण है:
  • हल्के कैशिंग अक्सर प्राप्त किए गए लेकिन छोटा सा डेटासेट एक बड़ा अंतर (कुछ ही सेकंड की अर्थात कैश जीवनकाल) होगा।
  • आपके द्वारा पहले से हाथ में आने वाले डेटा को फिर से प्राप्त न करें।
  • मल्टी-स्टेप स्टोरेज उन तालिकाओं में उच्च मात्रा में आवेषण के साथ मदद कर सकता है जिन्हें आसानी से पढ़ा जाता है। मूल विचार यह है कि आपके पास एड-हाॉक इन्सर्ट (INSERT DELAYED भी उपयोगी हो सकता है) के लिए एक टेबल हो सकती है, लेकिन वहां से बैच प्रक्रिया को वहां से MySQL के भीतर अपडेट करने के लिए जहां सभी पढ़े जा रहे हैं। इसमें भिन्नताएं हैं।
• भूल जाते हैं कि परिप्रेक्ष्य और संदर्भ, महत्वपूर्ण हैं भी नहीं है: क्या आप सोच सकते हैं एक लंबे समय के लिए एक UPDATE होने की वास्तव में काफी तुच्छ हो सकता है कि अगर "लंबे" अद्यतन दिन में केवल एक बार होता है के लिए है।

Answer 4

बहुत से सर्वोत्तम प्रथाएं हैं जिन पर पहले चर्चा की गई थी इसलिए उन्हें दोहराने का कोई कारण नहीं है। वास्तव में ठोस सलाह के लिए क्या करना है, मैं MySQL Tuner चलाने का प्रयास करूंगा। यह एक पर्ल स्क्रिप्ट है जिसे आप डाउनलोड कर सकते हैं और फिर अपने डेटाबेस सर्वर पर चला सकते हैं, यह आपको कुछ डेटाबेस या कॉन्फ़िगरेशन पैरामीटर को समायोजित करने की आवश्यकता के लिए कुछ ठोस अनुशंसाओं के साथ-साथ आपका डेटाबेस कैसा प्रदर्शन कर रहा है (उदाहरण के लिए कैश हिट) पर आंकड़ों का एक समूह देगा। प्रदर्शन में सुधार करने के लिए।

हालांकि ये आंकड़े सभी MySQL में उपलब्ध हैं, मुझे लगता है कि यह टूल उन्हें फैशन को समझने में बहुत आसान प्रदान करता है। हालांकि यह ध्यान रखना महत्वपूर्ण है कि सिफारिशों के संबंध में वाईएमएमवी, मैंने उन्हें आम तौर पर काफी सटीक पाया है। बस सुनिश्चित करें कि आपने यथार्थवादी यातायात के साथ पहले डेटाबेस का उपयोग करने के लिए एक अच्छी नौकरी की है।