खराब डेटाबेस प्रदर्शन हर डीबीए के लिए एक कांटा है। और प्रदर्शन के मुद्दों के मूल कारण को अलग करना हमेशा आसान नहीं होता है, जो केवल तनाव को बढ़ाता है।
अपने SQL सर्वर डेटाबेस को ट्यून करना आपकी कुछ प्रदर्शन समस्याओं को हल करने का एक शानदार तरीका है, लेकिन यह हमेशा स्पष्ट नहीं हो सकता है कि आपको अनुकूलन प्रक्रिया कहाँ से शुरू करनी चाहिए। यदि आप डिस्क स्थान, मेमोरी, और अन्य नेटवर्क और हार्डवेयर प्रदर्शन हत्यारों से इंकार करते हैं, और आपका SQL सर्वर प्रदर्शन अभी भी पिछड़ रहा है, तो यह आपके प्रश्नों में खुदाई करने का समय है।
गैर-अनुकूलित क्वेरी आपके सिस्टम के लिए असंख्य प्रदर्शन समस्याओं का कारण बन सकती हैं। उज्जवल पक्ष में, कुछ सामान्य क्वेरी गलतियाँ डेटाबेस के प्रदर्शन में गिरावट के लिए जिम्मेदार हैं।
यदि आपके प्रश्नों में इन छह समस्याओं में से कोई भी समस्या है, तो कुछ गंभीर प्रदर्शन ट्यूनिंग के लिए तैयार हो जाइए।
समस्या प्रश्न संख्या 1:प्रमुख वाइल्डकार्ड वाले भावों की तरह
प्रमुख वाइल्डकार्ड MySQL को इंडेक्स का उपयोग करने से रोकते हैं, एक पूर्ण टेबल स्कैन को मजबूर करते हैं, भले ही आपने टेबल के भीतर एक फ़ील्ड को अनुक्रमित किया हो। किसी तालिका में सभी पंक्तियों को स्कैन करने से आपके क्वेरी परिणामों का वितरण काफी धीमा हो जाता है, इसलिए दक्षता में सुधार करने के लिए अग्रणी वाइल्डकार्ड को हटा दें।
समस्या प्रश्न संख्या 2:गैर-अनुक्रमित कॉलम 'कहां' और 'ग्रुप बाय' क्लॉज में प्रयुक्त होते हैं
अनुक्रमण कॉलम क्वेरी परिणामों को तेज़ी से वापस करने में मदद करता है क्योंकि यह पूर्ण तालिका स्कैन की आवश्यकता को समाप्त करता है। अनुक्रमण रिकॉर्ड्स को लौटाए जाने पर उन्हें सॉर्ट करने में भी मदद करता है और गारंटी देता है कि वे रिकॉर्ड विशिष्ट रूप से पहचाने जाने योग्य हैं, जो विशेष रूप से 10 से अधिक पंक्तियों वाली तालिकाओं में उपयोगी होते हैं।
कुछ परिप्रेक्ष्य के लिए, अनुक्रमण से पहले और बाद में अपने क्वेरी विश्लेषण में "व्याख्या" कथन चलाने पर विचार करें। इससे आपको अंदाजा हो जाएगा कि आपने अभी-अभी अपने आप को स्कैन करने की कितनी पंक्तियों को सहेजा है।
समस्या प्रश्न संख्या 3:ऐसे कथन जो संघ खंड के बजाय 'या' ऑपरेटर का उपयोग करते हैं
तालिका में फ़ील्ड या कॉलम पर तुलना ऑपरेटर "या" का उपयोग करके क्वेरी चलाना उपयोगी हो सकता है, लेकिन "कहां" क्लॉज में "या" को बहुत बार लागू करना पूर्ण तालिका स्कैन के लिए एक और तेज़ ट्रैक है।
एक यूनियन क्लॉज SQL क्वेरी को तेजी से चला सकता है, खासकर यदि अलग-अलग इंडेक्स क्वेरी के प्रत्येक पक्ष को अनुकूलित कर रहे हों। अनिवार्य रूप से, संघ संचालक दो तेज़, अनुक्रमित प्रश्नों के परिणाम लेता है और उन्हें एक में मिला देता है।
समस्या प्रश्न संख्या 4:वाइल्डकार्ड खोज
यदि आप ऐसी स्थिति में फंस गए हैं जिसमें आपको वाइल्डकार्ड के साथ खोज करने की आवश्यकता है, लेकिन आप प्रदर्शन को प्रभावित नहीं करना चाहते हैं, तो MySQL पूर्ण-पाठ खोज का उपयोग करने का प्रयास करें। वाइल्डकार्ड वर्णों के साथ खोज करने की तुलना में पूर्ण-पाठ खोज काफी तेज़ हैं, और विशाल डेटाबेस खोजते समय आपको अधिक प्रासंगिक परिणामों का अतिरिक्त लाभ मिलता है।
समस्या प्रश्न संख्या 5:गैर-अनुकूलित डेटाबेस स्कीमा
आप केवल SQL क्वेरी प्रदर्शन में इतना सुधार कर सकते हैं यदि आप अपने डेटाबेस स्कीमा को भी अनुकूलित नहीं करते हैं। यहां सुधार के लिए कुछ सुझाव दिए गए हैं:
तालिकाओं को सामान्य करें
डेटा अतिरेक प्रदर्शन को नुकसान पहुंचाता है, इसलिए डेटाबेस में केवल एक बार तथ्य का प्रतिनिधित्व करना सुनिश्चित करें। उदाहरण के लिए, यदि किसी ग्राहक को एक से अधिक तालिका में संदर्भित किया जाता है, तो केवल एक बार “customer_name” का उपयोग करें, फिर बाद के संदर्भों के लिए “customer_ID” का उपयोग करें।
इष्टतम डेटा प्रकारों का उपयोग करें
डेटा प्रकारों के संबंध में याद रखने योग्य कुछ महत्वपूर्ण बिंदु:
- टेबल डिजाइन करते समय छोटा बेहतर है। उदाहरण के लिए, 100 से कम उपयोगकर्ताओं वाली सिस्टम उपयोगकर्ता तालिका के लिए "user_id" फ़ील्ड के लिए "TINYINT" डेटा प्रकार का उपयोग करें।
- यदि कोई फ़ील्ड दिनांक मान की अपेक्षा करता है तो "date_time" डेटा प्रकार का उपयोग करें ताकि आपको तथ्य के बाद रिकॉर्ड को दिनांक स्वरूप में परिवर्तित न करना पड़े।
- MySQL, वर्चर सहित, टेक्स्ट डेटा प्रकारों के मुकाबले पूर्णांक मानों के साथ बेहतर काम करता है।
शून्य मानों से बचें
कॉलम में शून्य मान आपके क्वेरी परिणामों को नुकसान पहुंचा सकते हैं, इसलिए आपको उन फ़ील्ड के लिए एक डिफ़ॉल्ट मान निर्दिष्ट करने की आवश्यकता हो सकती है जहां रिकॉर्ड के लिए अनिवार्य मान की आवश्यकता नहीं होती है।
बहुत अधिक कॉलम का उपयोग न करें
वाइड टेबल (100 से अधिक कॉलम) को प्रोसेस करने के लिए बहुत सारे CPU और संसाधनों की आवश्यकता होती है। जब तक आपको पूरी तरह से एक विस्तृत तालिका शामिल नहीं करनी है, इसे छोटे, तार्किक तालिकाओं में विभाजित करना बेहतर है।
जॉइन को ऑप्टिमाइज़ करें
बहुत अधिक जुड़ने वाले SQL कथन (और बहुत अधिक तालिकाओं के साथ जुड़ते हैं) प्रदर्शन को नकारात्मक रूप से प्रभावित करते हैं। प्रत्येक क्वेरी के लिए 12 से अधिक जॉइन के लिए शूट करें।
समस्या क्वेरी नंबर 6:अन-कैश्ड MySQL क्वेरीज़
बहुत सारी चुनिंदा क्वेरी करने वाली वेबसाइटें और एप्लिकेशन MySQL क्वेरीज़ को कैशिंग करने से लाभान्वित होंगे। MySQL क्वेरी कैशिंग रीड ऑपरेशंस के दौरान प्रदर्शन को गति देता है क्योंकि यह परिणामी डेटा सेट के साथ चुनिंदा क्वेरी को कैश करता है और यदि क्वेरी को एक से अधिक बार निष्पादित किया जाता है तो मेमोरी (डिस्क नहीं) से प्राप्त होता है।
आपके SQL सर्वर डेटाबेस के लिए उच्च उपलब्धता बनाए रखने और आपके अंतिम उपयोगकर्ता खुश हैं यह सुनिश्चित करने के लिए प्रदर्शन ट्यूनिंग आवश्यक है। लेकिन दुर्भाग्य से, यह हमेशा तुरंत स्पष्ट नहीं होता है कि ट्यूनिंग की सबसे अधिक आवश्यकता कहाँ है। यदि आपने प्रदर्शन समस्याओं के लिए स्पष्ट नेटवर्क और हार्डवेयर स्रोतों को हटा दिया है, तो अपना ध्यान अपने प्रश्नों पर केंद्रित करें।
यदि आप किसी भी लम्बे समय से डीबीए के रूप में काम कर रहे हैं, तो आपको इन समस्या प्रश्नों में से एक (या सभी) का सामना करना पड़ सकता है। अब जब आप जानते हैं कि क्या देखना है, तो अपनी प्रदर्शन सुधार पहल में सक्रिय रहें और इन सामान्य क्वेरी दर्द बिंदुओं को ठीक करें ताकि आप SQL सर्वर क्वेरी ऑप्टिमाइज़ेशन के पुरस्कार प्राप्त कर सकें।
