मुझे यह भी लगता है कि आप Oracle का उपयोग कर रहे हैं। और मैं यह भी अनुशंसा करता हूं कि आप शुरुआत के लिए व्याख्या योजना वेब पेज देखें। अनुकूलन के लिए बहुत कुछ है, लेकिन इसे सीखा जा सकता है।
कुछ सुझाव इस प्रकार हैं:
सबसे पहले, जब कोई आपको अनुकूलित करने के लिए कार्य करता है, तो वे लगभग हमेशा अंतिम प्रदर्शन के बजाय स्वीकार्य प्रदर्शन की तलाश में रहते हैं। यदि आप किसी क्वेरी के चलने के समय को 3 मिनट से घटाकर 3 सेकंड कर सकते हैं, तो इसे कम करके 2 सेकंड तक न करें, जब तक कि आपसे ऐसा करने के लिए न कहा जाए।
दूसरा, यह सुनिश्चित करने के लिए एक त्वरित जांच करें कि आप जिन प्रश्नों का अनुकूलन कर रहे हैं वे तार्किक रूप से सही हैं। यह बेतुका लगता है, लेकिन मैं आपको यह नहीं बता सकता कि मुझसे धीमी गति से चलने वाली क्वेरी पर कितनी बार सलाह मांगी गई है, केवल यह पता लगाने के लिए कि यह कभी-कभी गलत उत्तर दे रही थी! और जैसा कि यह पता चला है, क्वेरी को डीबग करना अक्सर इसे गति देने के लिए निकला।
विशेष रूप से, व्याख्या योजना में "कार्टेशियन जॉइन" वाक्यांश देखें। यदि आप इसे वहां देखते हैं, तो संभावना बहुत अच्छी है कि आपको अनजाने में कार्टेशियन जॉइन मिल गया है। एक अनजाने कार्टेशियन जॉइन के लिए सामान्य पैटर्न यह है कि FROM क्लॉज कॉमा द्वारा अलग की गई टेबल को सूचीबद्ध करता है, और जॉइन की स्थिति WHERE क्लॉज में होती है। सिवाय इसके कि शामिल होने की शर्तों में से एक गायब है, ताकि Oracle के पास कार्टेशियन जॉइन करने के अलावा कोई विकल्प न हो। बड़ी तालिकाओं के साथ, यह एक प्रदर्शन आपदा है।
व्याख्या योजना में कार्टेशियन जॉइन देखना संभव है जहां क्वेरी तार्किक रूप से सही है, लेकिन मैं इसे ओरेकल के पुराने संस्करणों से जोड़ता हूं।
अप्रयुक्त यौगिक सूचकांक भी देखें। यदि कंपाउंड इंडेक्स के पहले कॉलम का उपयोग क्वेरी में नहीं किया जाता है, तो Oracle इंडेक्स को अक्षम रूप से उपयोग कर सकता है, या बिल्कुल नहीं। मैं एक उदाहरण देता हूं:
क्वेरी थी:
select * from customers
where
State = @State
and ZipCode = @ZipCode
(डीबीएमएस ओरेकल नहीं था, इसलिए वाक्यविन्यास अलग था, और मैं मूल वाक्यविन्यास भूल गया हूं)।
इंडेक्स पर एक त्वरित नज़र ने उस क्रम में कॉलम (देश, राज्य, ज़िप कोड) वाले ग्राहकों पर एक इंडेक्स का खुलासा किया। मैंने पढ़ने के लिए क्वेरी बदल दी है
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
और अब यह लगभग 6 मिनट के बजाय लगभग 6 सेकंड में चला, क्योंकि अनुकूलक अच्छे लाभ के लिए सूचकांक का उपयोग करने में सक्षम था। मैंने एप्लिकेशन प्रोग्रामर्स से पूछा कि उन्होंने देश को मानदंड से क्यों हटा दिया, और यह उनका जवाब था:वे जानते थे कि सभी पतों में 'यूएसए' के बराबर देश था, इसलिए उन्हें लगा कि वे उस मानदंड को छोड़कर क्वेरी को तेज कर सकते हैं!
दुर्भाग्य से, डेटाबेस पुनर्प्राप्ति का अनुकूलन वास्तव में कंप्यूटिंग समय से माइक्रोसेकंड को शेविंग करने जैसा नहीं है। इसमें डेटाबेस डिज़ाइन, विशेष रूप से अनुक्रमित, और कम से कम एक सिंहावलोकन को समझना शामिल है कि ऑप्टिमाइज़र अपना काम कैसे करता है।
आप आमतौर पर ऑप्टिमाइज़र से बेहतर परिणाम प्राप्त करते हैं जब आप इसे बेहतर बनाने की कोशिश करने के बजाय इसके साथ सहयोग करना सीखते हैं।
ऑप्टिमाइज़ेशन में तेज़ी आने के लिए शुभकामनाएँ!
