बुरी खबर:इसमें मदद करने के लिए जीयूआई उपकरण हैं, लेकिन यह एक कुशल और व्यापक नौकरी है। इसलिए वे सब कुछ कवर नहीं करते हैं, इसकी संभावना है कि आपको मदद के लिए कमांड लाइन सामान/एसक्यूएल स्टेटमेंट आदि का उपयोग करने की आवश्यकता होगी। मैंने वास्तव में केवल कमांड लाइन टूल्स का उपयोग किया है। मैं उन चीजों का एक संक्षिप्त विवरण दूंगा जिन्हें मैं जानता/उपयोग करता हूं:
सबसे पहले, आपको एक अच्छे डेटाबेस डिज़ाइन की आवश्यकता है। यदि डिज़ाइन खराब है, तो आप केवल इतनी दूर जा सकते हैं। इसमें सामान्यीकरण, साथ ही फ़ील्ड के लिए उपयुक्त प्रकारों का उपयोग करना शामिल है। मैं इस बिंदु को यहाँ छोड़ता हूँ, क्योंकि मुझे लगता है कि यह थोड़ा अलग है, न कि आप जो चाहते हैं।
सुनिश्चित करें कि MySQL क्वेरी कैश सेट है और काम कर रहा है और यदि आप कर सकते हैं तो इसे थोड़ा और RAM दें, और सुनिश्चित करें कि आपके महत्वपूर्ण प्रश्न ऐसा कुछ भी नहीं कर रहे हैं जो MySQL को कैशिंग करने से रोकता है। उदाहरण के लिए, प्रश्नों में नाओ () फ़ंक्शन का उपयोग करने से ऐसा होता है - स्पष्ट कारणों से - अब हर सेकेंड में बदलता है! इसके बजाय आप sql में टाइमस्टैम्प लगा सकते हैं, और समय का उपयोग निकटतम मिनट/घंटे/दिन (सबसे बड़ी अवधि जिसे आप दूर कर सकते हैं) के लिए कर सकते हैं ताकि mysql को कुछ कैशिंग लाभ मिल सके।
चीजों का अनुकूलन शुरू करने के लिए:चयन के सामने "EXPLAIN" चिपकाना यह देखने का तरीका है कि किसी क्वेरी को कैसे निष्पादित किया जा रहा है और इसे सुधारने के तरीके की पहचान करें। आउटपुट की व्याख्या करना सीखें:http://dev.mysql .com/doc/refman/5.0/hi/using-explain.html चीजों को बेहतर बनाने के लिए आप अक्सर नए इंडेक्स जोड़ सकते हैं/मौजूदा में कॉलम जोड़ सकते हैं। लेकिन आपको ऐसे समय का भी सामना करना पड़ेगा जब प्रश्नों को पुनर्गठित करने की आवश्यकता होगी।
MySQL के साथ प्रदर्शन में सुधार शुरू करना (यह मानते हुए कि आप पहले से ही नहीं जानते कि समस्या क्वेरी क्या है) धीमी क्वेरी लॉग की जांच करना है - यह एक फ़ाइल में लॉग करता है जिसमें सभी प्रश्न x सेकंड से अधिक समय लेते हैं।
अगर यह पहले से लॉगिंग नहीं कर रहा है तो इसके लिए कॉन्फिगरेशन सहित ओवरव्यू, यहां है:http://dev.mysql.com/doc/refman/5.0/hi/slow-query-log.html - मैंने यह भी पाया है कि एक या एक दिन के लिए long_query_time को 0 पर सेट करना, ताकि सभी प्रश्नों को यहां समय के साथ लॉग किया जा सके, यह पता लगाने का एक उपयोगी तरीका है कि प्रदर्शन कहां जा रहा है। लेकिन मैं तुरंत वहाँ नहीं जाऊँगा! और इसे चालू न रखें, लॉग बड़े पैमाने पर हो सकते हैं।
लॉगिंग के कुछ दिनों के बाद, मुझे यहाँ से mysqlsla (mysql स्लो लॉग एनालाइज़र) मिल गया है:http://hackmysql.com/mysqlsla एक अच्छा उपकरण है।
यह केवल धीमी क्वेरी लॉग विश्लेषण से अधिक कर सकता है - मैनुअल पढ़ें। लेकिन यह समझाने के लिए कि यह धीमे लॉग के लिए क्या करता है:धीमी क्वेरी लॉग में बहुत अधिक डेटा हो सकता है, इसलिए यह पता लगाना कठिन हो सकता है कि कुल मिलाकर कौन से प्रश्न सबसे महंगे हैं - उदाहरण:कारक कितनी बार चलते हैं और कब दो प्रश्न वास्तव में एक ही खंड में एक अलग आईडी के साथ समान हैं।
MySQL sla यह सब आपके लिए करता है। यह लॉग के माध्यम से चलता है, और उन प्रश्नों को समूहित कर सकता है जो समान हैं/जहां खंडों में अलग-अलग मान हैं। यह तब आपको (डिफ़ॉल्ट रूप से) कुल निष्पादन समय के संदर्भ में शीर्ष 10 प्रश्न प्रस्तुत करता है - जिसमें अक्सर कुछ आश्चर्य होता है, लेकिन आमतौर पर सबसे अधिक उत्पादक प्रारंभिक बिंदु होता है - सबसे महंगी क्वेरी लें और उस पर EXPLAIN का उपयोग करें और देखें कि क्या आप सुधार कर सकते हैं यह।
कुछ प्रश्नों में लंबा समय लगता है, और इन्हें आसानी से सुधारा नहीं जा सकता है। इस मामले में, क्या आप डेटा को किसी अन्य तरीके से प्राप्त कर सकते हैं या कम से कम इसे कैश कर सकते हैं? आप यह भी पा सकते हैं कि डीबी स्कीमा को बदलने की आवश्यकता है। इसी तरह, कुछ प्रश्न mysqlsla आउटपुट के शीर्ष पर हो सकते हैं क्योंकि आप उन्हें बहुत चलाते हैं (विशेष रूप से सच अगर long_query_time 0 पर सेट है), भले ही वे बहुत तेज दौड़ें। हो सकता है कि आपके ऐप में कुछ कैशिंग जोड़ने का समय हो?
http://www.maatkit.org/ यह भी आशाजनक दिखता है - इसका कभी भी उपयोग नहीं किया, लेकिन एमके-क्वेरी-प्रोफाइलर टूल आगे यह देखने के लिए उपयोगी होना चाहिए कि प्रश्न धीमे क्यों हैं।
साथ ही देखने के लिए एक पूरी तरह से अलग चीज:PHPMYADMIN में "स्थिति" पृष्ठ (या आप इस जानकारी को उत्पन्न करने के लिए सभी प्रश्नों को चला सकते हैं ....) - यह उन चीजों को हाइलाइट करता है जो सोचते हैं कि लाल रंग में खराब हो सकता है, और आपकी मदद कर सकता है देखें कि आपको सिस्टम संसाधन आवंटित करने से कहाँ लाभ मिल सकता है। मैं इसके बारे में इतना नहीं जानता - मेरा दृष्टिकोण हमेशा यह रहा है कि अगर कुछ लाल है और खराब दिखता है, तो इसके बारे में पढ़ने और यह तय करने के लिए कि क्या यह महत्वपूर्ण है और क्या मुझे कुछ करना चाहिए (आमतौर पर इसका मतलब है कि MySQL को अधिक संसाधन आवंटित करना) कॉन्फिग बदलकर)।
हाल ही में मैंने पाया है कि शो प्रोसेसलिस्ट चलाना एक सर्वर पर भी उपयोगी हो सकता है जो पीड़ित है। जबकि यह आपको केवल लाइव (अच्छी तरह से, एक लाइव स्नैपशॉट) जानकारी देता है, यह आपको यह महसूस करने में मदद कर सकता है कि एक निश्चित समय में क्या हो रहा है, खासकर यदि आप कुछ बार ताज़ा करते हैं और परिवर्तनों का निरीक्षण करते हैं। मैंने हाल ही में इस विधि का उपयोग करके एक समान क्वेरी चलाने के लिए प्रत्येक उपलब्ध MySQL कनेक्शन का उपयोग कर एक सर्वर देखा है। निश्चित रूप से, यह धीमी क्वेरी लॉग में होता, लेकिन यह देखने के लिए कि क्या हो रहा था, यह वास्तव में एक त्वरित और स्पष्ट तरीका है।
