जरूरी नहीं कि इंडेक्स प्रदर्शन में सुधार करें। क्या हो रहा है, इसे बेहतर ढंग से समझने के लिए, यदि आप explain . शामिल करते हैं तो इससे मदद मिलेगी विभिन्न प्रश्नों के लिए।
मेरा सबसे अच्छा अनुमान यह होगा कि आपके पास id_state . में एक अनुक्रमणिका है या यहां तक कि id_state, id_mp जिसका उपयोग where . को संतुष्ट करने के लिए किया जा सकता है खंड। यदि ऐसा है, तो पहली क्वेरी बिना order by . के इस सूचकांक का उपयोग करेंगे। यह काफी तेज होना चाहिए। अनुक्रमणिका के बिना भी, इसके लिए orders . में पृष्ठों के क्रमिक स्कैन की आवश्यकता होती है तालिका, जो अभी भी बहुत तेज़ हो सकती है।
फिर जब आप creation_date पर अनुक्रमणिका जोड़ते हैं , MySQL order by . के बजाय उस अनुक्रमणिका का उपयोग करने का निर्णय लेता है . इसके लिए अनुक्रमणिका में प्रत्येक पंक्ति को पढ़ने की आवश्यकता होती है, फिर where . की जांच करने के लिए संबंधित डेटा पृष्ठ लाने की आवश्यकता होती है शर्तें और कॉलम वापस करें (यदि कोई मेल है)। यह पठन अत्यधिक अक्षम है, क्योंकि यह "पृष्ठ" क्रम में नहीं है बल्कि सूचकांक द्वारा निर्दिष्ट है। यादृच्छिक पठन काफी अक्षम हो सकता है।
इससे भी बदतर, भले ही आपके पास limit . हो , आपको अभी भी संपूर्ण . पढ़ना है तालिका क्योंकि पूरे परिणाम सेट की आवश्यकता है। यद्यपि आपने 38 रिकॉर्ड पर एक प्रकार को सहेजा है, आपने एक व्यापक रूप से अक्षम क्वेरी बनाई है।
वैसे, orders . अगर यह स्थिति काफी खराब हो जाती है तालिका उपलब्ध स्मृति में फिट नहीं होती है। फिर आपके पास "थ्रैशिंग" नामक एक शर्त है, जहां प्रत्येक नया रिकॉर्ड एक नया I/O रीड उत्पन्न करता है। इसलिए, यदि किसी पृष्ठ पर 100 रिकॉर्ड हैं, तो पृष्ठ को 100 बार पढ़ना पड़ सकता है।
orders(id_state, id_mp, creation_date) पर एक इंडेक्स बनाकर आप इन सभी प्रश्नों को तेजी से चला सकते हैं . where क्लॉज पहले दो कॉलम और order by . का उपयोग करेगा अंतिम का उपयोग करेंगे।
