MySQL
मैसकल प्रदर्शन युक्तियाँ

स्टेटमेंट ऑप्टिमाइज़ेशन चुनें

नीचे कुछ सुझाव दिए गए हैं जब हम MySQL में एक चुनिंदा क्वेरी लिख रहे हैं जो हमें याद रखने में मदद कर सकती है और हमारे क्वेरी समय को कम कर सकती है: -

1. जब भी हम एक बड़ी तालिका में उपयोग करते हैं, तो हमें यह सुनिश्चित करना चाहिए कि जहां खंड अनुक्रमणिका में है, वह स्तंभ है या नहीं। Ex: - कर्मचारी से चुनें * जहाँ user_id> 2000. user_id यदि अनुक्रमित है तो क्वेरी एटलॉट के मूल्यांकन को गति देगा। इंडेक्स और फॉरेन कीज के दौरान इंडेक्स भी बहुत महत्वपूर्ण होते हैं।

2. जब आपको सामग्री के छोटे सेक्शन की आवश्यकता होती है, तब तालिका से संपूर्ण डेटा प्राप्त करना, सीमा का उपयोग करने का प्रयास करना। बल्कि उसके बाद Ex: - कर्मचारी से * सेलेक्ट करें। यदि आपको लाख से पहले 20 कर्मचारी की आवश्यकता है, तो बस सीमा का उपयोग करें Ex: - कर्मचारी से 20 का चयन करें *।

3. आप परिणाम में इच्छित कॉलम नाम प्रदान करके अपनी क्वेरी को भी अनुकूलित कर सकते हैं। बल्कि उसके बाद Ex: - कर्मचारी से * सेलेक्ट करें। बस उस स्तंभ नाम का उल्लेख करें जिसमें से आपको डेटा की आवश्यकता है यदि आपके पास तालिका में बहुत सारे स्तंभ हैं और आप उनमें से कुछ के लिए डेटा चाहते हैं। Ex: - कर्मचारी से आईडी, नाम चुनें।

4. यदि आप खंड में NULL के लिए सत्यापन करने के लिए उपयोग कर रहे हैं तो इंडेक्स कॉलम। यदि आपके पास SELECT * FROM tbl_name के रूप में कुछ स्टेटमेंट है, तो key_col IS NULL है; तब यदि key_col अनुक्रमित किया जाता है तो क्वेरी का तेजी से मूल्यांकन किया जाएगा।

InnoDB टेबल्स के लिए भंडारण लेआउट का अनुकूलन

1. InnoDB में, एक लंबी प्राथमिक कुंजी (या तो एक लंबा मान के साथ एक एकल स्तंभ, या एक लंबा समग्र मान बनाने वाले कई स्तंभ) डिस्क स्थान की बहुत बर्बाद करता है। किसी पंक्ति के लिए प्राथमिक कुंजी मान को सभी द्वितीयक अनुक्रमणिका रिकॉर्ड में डुप्लिकेट किया जाता है जो एक ही पंक्ति को इंगित करता है। यदि आपकी प्राथमिक कुंजी लंबी है, तो प्राथमिक कुंजी के रूप में एक AUTO_INCREMENT कॉलम बनाएँ।
2. चर-लंबाई के तार या कई NULL मान वाले स्तंभों को संग्रहीत करने के लिए CHAR के बजाय VARCHAR डेटा प्रकार का उपयोग करें। एक CHAR (N) कॉलम हमेशा डेटा को स्टोर करने के लिए N अक्षर लेता है, भले ही स्ट्रिंग छोटा हो या उसका मूल्य NULL हो। छोटी तालिकाओं बफर पूल में बेहतर फिट होती हैं और डिस्क I / O को कम करती हैं।

COMPACT पंक्ति प्रारूप (डिफ़ॉल्ट InnoDB प्रारूप) और चर-लंबाई वर्ण सेट, जैसे कि utf8 या sjis, CHAR (N) कॉलम का उपयोग करते समय अंतरिक्ष की एक चर राशि पर कब्जा होता है, लेकिन फिर भी कम से कम N बाइट्स।

3. उन तालिकाओं के लिए जो बड़ी हैं, या बहुत दोहराव वाले पाठ या संख्यात्मक डेटा शामिल हैं, COMPRESSED पंक्ति प्रारूप का उपयोग करने पर विचार करें। बफर डिस्क में डेटा लाने के लिए, या पूर्ण टेबल स्कैन करने के लिए कम डिस्क I / O की आवश्यकता होती है। एक स्थायी निर्णय लेने से पहले, संपीड़न बनाम कम्पैक्ट पंक्ति प्रारूप का उपयोग करके आप कितनी मात्रा में संपीड़न प्राप्त कर सकते हैं। कैविएट: बेंचमार्क शायद ही कभी 2: 1 संपीड़न से बेहतर दिखाते हैं और कंप्रेश के लिए बफर_पुल में बहुत अधिक ओवरहेड होता है।
4. एक बार जब आपका डेटा एक स्थिर आकार तक पहुँच जाता है, या एक बढ़ती हुई तालिका दसियों या कुछ सैकड़ों मेगाबाइट्स से बढ़ गई है, तो तालिका को पुनर्गठित करने और किसी भी बर्बाद स्थान को कॉम्पैक्ट करने के लिए ऑप्टिमाइज़ टेबल स्टेटमेंट का उपयोग करने पर विचार करें। पुनर्गठित तालिकाओं को पूर्ण तालिका स्कैन करने के लिए कम डिस्क I / O की आवश्यकता होती है। यह एक सीधी तकनीक है जो प्रदर्शन में सुधार कर सकती है जब अन्य तकनीकों जैसे कि अनुक्रमण उपयोग या ट्यूनिंग एप्लिकेशन कोड में सुधार व्यावहारिक नहीं है। कैविएट : टेबल आकार के बावजूद, ऑप्टिमाइज़ टेबल को केवल शायद ही कभी प्रदर्शन किया जाना चाहिए। ऐसा इसलिए है क्योंकि यह महंगा है, और शायद ही कभी मेज को बेहतर बनाता है कि इसके लायक हो। InnoDB अपने B + पेड़ों को बहुत सारे बर्बाद स्थान से मुक्त रखने में यथोचित रूप से अच्छा है।

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

एक समग्र सूचकांक का निर्माण

कई स्थितियों में, एक संयुक्त सूचकांक एक एकल स्तंभ के साथ एक सूचकांक से बेहतर प्रदर्शन करता है। एक इष्टतम समग्र सूचकांक बनाने के लिए, इसे इस क्रम में कॉलम के साथ आबाद करें।

• WHERE क्लॉज से = कॉलम (एस)। (उदाहरण के लिए, INDEX(a,b,...) लिए WHERE a=12 AND b='xyz' ... )
• IN स्तंभ (रों); आशावादी सूचकांक के माध्यम से छलांग लगाने में सक्षम हो सकता है।
• एक "रेंज" (उदाहरण के लिए x BETWEEN 3 AND 9 , name LIKE 'J%' ) यह पहली श्रेणी के कॉलम से पहले किसी भी चीज का उपयोग नहीं करेगा।
• GROUP BY सभी कॉलम, क्रम में
• ORDER BY सभी कॉलम, क्रम में। केवल तभी काम करता है जब सभी ASC या सभी DESC या आप 8.0 का उपयोग कर रहे हैं।

नोट और अपवाद:

• किसी भी कॉलम की नकल न करें।
• लागू न होने वाले किसी भी मामले को छोड़ दें।
• यदि आप WHERE सभी कॉलम का उपयोग नहीं करते हैं, तो GROUP BY , आदि पर जाने की कोई आवश्यकता नहीं है।
• ऐसे मामले हैं जहां केवल ORDER BY कॉलम को अनुक्रमित करना उपयोगी है, WHERE अनदेखी की गई है।
• किसी फ़ंक्शन (उदाहरण के लिए DATE(x) = ... किसी कॉलम को "छुपाना नहीं चाहिए" DATE(x) = ... सूचकांक में x का उपयोग नहीं कर सकता।)
• 'उपसर्ग' अनुक्रमण (जैसे, text_col(99) ) सहायक होने की संभावना नहीं है; चोट लग सकती है।

अधिक जानकारी और सुझाव ।