देखें MySQL इंडेक्स का उपयोग कैसे करता है ।
यह भी सत्यापित करें कि क्या MySQL अभी भी पूर्ण तालिका स्कैन करता है अपने user_metrics . में अतिरिक्त 2000-या-तो पंक्तियाँ जोड़ने के बाद टेबल। छोटी तालिकाओं में, एक्सेस-बाय-इंडेक्स वास्तव में टेबल स्कैन की तुलना में अधिक महंगा (I/O-wise) होता है, और MySQL का ऑप्टिमाइज़र इसे ध्यान में रख सकता है।
मेरी पिछली पोस्ट के विपरीत , यह पता चला है कि MySQL भी लागत-आधारित अनुकूलक का उपयोग कर रहा है
, जो बहुत अच्छी खबर है - यानी, बशर्ते आप अपना ANALYZE . चलाएं कम से कम एक बार जब आपको लगता है कि आपके डेटाबेस में डेटा की मात्रा प्रतिनिधि है भविष्य के दैनिक उपयोग के लिए।
लागत-आधारित अनुकूलक (Oracle, Postgres, आदि) के साथ काम करते समय, आपको समय-समय पर ANALYZE
आपकी विभिन्न टेबलों पर जैसे-जैसे उनका आकार 10-15% से अधिक बढ़ता है। (पोस्टग्रेज डिफ़ॉल्ट रूप से आपके लिए यह स्वचालित रूप से करेगा, जबकि अन्य आरडीबीएमएस इस जिम्मेदारी को एक डीबीए, यानी आप पर छोड़ देंगे।) सांख्यिकीय विश्लेषण के माध्यम से, ANALYZE विभिन्न उम्मीदवार निष्पादन योजनाओं के बीच चयन करते समय ऑप्टिमाइज़र को इस बात का बेहतर विचार प्राप्त करने में मदद मिलेगी कि I/O (और अन्य संबद्ध संसाधन, जैसे CPU, जैसे सॉर्टिंग के लिए आवश्यक) कितना शामिल होगा। ANALYZE चलाने में विफलता इसके परिणामस्वरूप बहुत खराब, कभी-कभी विनाशकारी नियोजन निर्णय हो सकते हैं (उदाहरण के लिए मिलीसेकंड-क्वेरी लेना, कभी-कभी, खराब नेस्टेड लूप के कारण घंटे पर JOIN स.)
यदि ANALYZE चलाने के बाद भी प्रदर्शन असंतोषजनक है तो , तो आप आमतौर पर संकेतों का उपयोग करके समस्या को हल करने में सक्षम होंगे, उदा। FORCE INDEX , जबकि अन्य मामलों में आप एक MySQL बग पर ठोकर खा सकते हैं (उदाहरण के लिए यह पुराना वाला , जो आपको काट सकता था यदि आप रेल के nested_set . का उपयोग करते थे )।
अब, चूंकि आप एक रेल ऐप में हैं , यह बोझिल होगा (और ActiveRecord . के उद्देश्य को विफल कर देगा) ) ActiveRecord . का उपयोग जारी रखने के बजाय अपने कस्टम प्रश्नों को संकेतों के साथ जारी करने के लिए -जनरेटेड वाले।
मैंने उल्लेख किया था कि हमारे रेल आवेदन में सभी SELECT Postgres पर स्विच करने के बाद क्वेरी 100ms से नीचे चली गई, जबकि कुछ जटिल ActiveRecord द्वारा उत्पन्न हुए हैं इंडेक्स उपलब्ध होने पर भी, आंतरिक टेबल स्कैन के साथ नेस्टेड लूप के कारण कभी-कभी MySQL 5.1 के साथ 15 या उससे अधिक का समय लगता है। कोई भी ऑप्टिमाइज़र सही नहीं है, और आपको विकल्पों के बारे में पता होना चाहिए। क्वेरी प्लान ऑप्टिमाइजेशन के अलावा अन्य संभावित प्रदर्शन समस्याओं के बारे में पता होना चाहिए, जो लॉक हो रही हैं। हालांकि यह आपकी समस्या के दायरे से बाहर है।
