MySQL में क्वेरी प्रदर्शन अनुकूलन

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

कुछ प्रश्न धीमे क्यों होते हैं?

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

1. क्या SQL क्वेरी बहुत अधिक कॉलम या पंक्तियों तक पहुंच पाएगी?
2. क्या MySQL सर्वर वांछित परिणाम प्राप्त करने के लिए बहुत अधिक पंक्तियों का विश्लेषण करेगा?

ऐसे प्रश्न हैं जो MySQL सर्वर को बहुत अधिक डेटा पर विश्लेषण करते हैं, लेकिन जैसे ही यह झारना होता है, उन्हें फेंक देता है। नेटवर्क ओवरहेड, बहुत अधिक मेमोरी खपत या सर्वर पर बहुत अधिक CPU संसाधन उपयोग जैसे कई पहलुओं के संदर्भ में सर्वर के लिए यह एक अतिरिक्त कार्य है। परिणाम धीमा प्रदर्शन है।

ऐसी स्थितियाँ हैं जहाँ आप इसके डिज़ाइन के दौरान बहुत मदद करने में सक्षम नहीं हो सकते हैं, लेकिन एक ऐसी स्थिति है जहाँ यदि आप सावधान हैं और परिणाम का अनुमान लगाते हैं और आत्मनिरीक्षण करते हैं, तो एक खराब क्वेरी को बेहतर नहीं तो कम से कम अच्छा बनाया जा सकता है।

विशिष्ट गलतियां और उनके समाधान

प्रश्न लिखते समय अक्सर कुछ सामान्य गलतियाँ होती हैं। यहां उनमें से कुछ हैं। आप उसी लाइन पर कुछ और सोच पा सकते हैं। संभावित समाधानों के साथ धीमी क्वेरी प्रदर्शन के कारण यहां दिए गए हैं।

बहुत अधिक पंक्तियां

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

हालांकि, ऐसी स्थिति में आप क्वेरी के साथ LIMIT क्लॉज का उपयोग करके समाधान प्रदान कर सकते हैं।

SELECT
      col1, col2,...
FROM
      table_name
LIMIT
      [offset,] count; 

LIMIT क्लॉज एक या दो पैरामीटर स्वीकार करता है। पहला ऑफसेट निर्दिष्ट करता है, और दूसरा गिनती निर्दिष्ट करता है। यदि केवल एक पैरामीटर निर्दिष्ट किया गया है तो यह परिणाम सेट की शुरुआत से पंक्तियों की संख्या को दर्शाता है।

उदाहरण के लिए, तालिका से 10 पंक्तियों का चयन करने के लिए, आप लिख सकते हैं:

SELECT
      e.emp_name, e.phone, e.email
FROM 
      employee e
LIMIT 10;

और अगली 10 पंक्तियों को चुनने के लिए, 11 रिकॉर्ड से शुरू करके, आप लिख सकते हैं:

SELECT
      e.emp_name, e.phone, e.email
FROM
      employee e
LIMIT 10, 10;

बहुत अधिक कॉलम

प्रश्न को हमेशा देखें:संदेह के साथ * चुनें। यह क्वेरी सभी कॉलम लौटाती है और आपको शायद उनमें से कुछ ही चाहिए। सभी स्तंभों को पुनः प्राप्त करने का सबसे बड़ा नुकसान यह है कि यह अनुक्रमणिका के उपयोग में बाधा डालकर अनुकूलन को रोकता है, सर्वर से बहुत अधिक I/O, मेमोरी और CPU संसाधनों की मांग करता है।

समझें कि सभी स्तंभों को पुनर्प्राप्त करने वाली ऐसी सार्वभौमिक क्वेरी बेकार हो सकती है। कुछ लोग कहते हैं कि वे उपयोगी हैं क्योंकि यह डेवलपर को एक ही बिट कोड का एक से अधिक स्थानों पर उपयोग करने देता है। यह ठीक है अगर इसमें शामिल लागत विचार के भीतर सीमित है। कभी-कभी पुनर्प्राप्त डेटा को कैशिंग करना इस संदर्भ में मदद करता है। लेकिन सावधान रहें, प्रदर्शन का लाभ उठाना एक आसान काम है और इस तरह की विलासिता में प्रदर्शन के लिए जगह नहीं हो सकती है।

अंगूठे का नियम इस तरह के सार्वभौमिक प्रश्नों से बचने या यथासंभव कम से कम कॉलम प्राप्त करने के लिए है।

अत्यधिक डेटा विश्लेषण

प्रश्न वांछित परिणाम लौटाते हैं जो ठीक है लेकिन कभी-कभी इन प्रश्नों को इस तरह से लिखा जाता है कि प्रसंस्करण करते समय परिणाम उत्पन्न करने से पहले बहुत अधिक डेटा की जांच करने की आवश्यकता होती है। इसलिए, MySQL में आपको निम्न लागत मीट्रिक के अनुसार मापना चाहिए:

• निष्पादन का समय
• पंक्तियों की जांच की गई
• कॉलम की जांच की गई

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

एक धीमी क्वेरी लॉग आमतौर पर /var/log/mysql/mysql-slow.log

ध्यान दें, किसी को mysqld.cnf में धीमी क्वेरी लॉगिंग को सेट और सक्षम करना पड़ सकता है कॉन्फ़िगरेशन फ़ाइल इस प्रकार है।

#slow_query_log = 1
#slow_query_log_file = /var/log/mysql/mysql-slow.log
#long_query_time = 2 

MySQL 5 से पहले और उसके साथ गंभीर सीमाएँ थीं, विशेष रूप से फाइन-ग्रेन्ड लॉगिंग के लिए समर्थन की कमी थी। केवल राहत उन पैच का उपयोग कर रही थी जो लॉगिंग को सक्षम करते थे। हालांकि, यह सुविधा इसकी मुख्य विशेषता के हिस्से के रूप में MySQL 5.1 और बाद के सर्वरों का हिस्सा रही है।

जिन प्रश्नों के निष्पादन में बहुत अधिक समय लगता है, उनका अर्थ यह नहीं है कि वे खराब प्रश्न हैं। धीमी क्वेरी लॉग केवल क्वेरी प्रदर्शन की जांच करने और इसे यथासंभव सुधारने का अवसर प्रदान करता है।

पुनर्गठन क्वेरी

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

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

निष्कर्ष

क्वेरी ऑप्टिमाइज़ेशन के लिए ये कुछ त्वरित युक्तियाँ हैं। समझें कि, SQL सिंटैक्स को जानना, एक क्वेरी बनाने में सक्षम है जो वांछित परिणाम प्राप्त करता है, यदि कोई क्वेरी प्रदर्शन का लक्ष्य रखता है तो पर्याप्त नहीं है। सरल दिखने वाले प्रश्नों के नीचे होने वाली घटनाओं को समझना महत्वपूर्ण है, जो न केवल वांछित चीज़ों को पुनः प्राप्त करता है बल्कि अनुकूलन की कला को वहीं से शुरू करता है जहां से यह सब शुरू होता है। क्वेरी प्रोसेसिंग के पीछे का दृश्य क्वेरी प्रदर्शन को समझने के लिए एक महत्वपूर्ण सुराग देता है और क्वेरी ऑप्टिमाइज़ेशन के क्षेत्र में प्रवेश करने से पहले यह ज्ञान आवश्यक है।