समस्या यह है कि क्वेरी निष्पादित करते समय MySQL केवल एक अनुक्रमणिका का उपयोग करता है। यदि आप एक नई अनुक्रमणिका जोड़ते हैं जो आपके WHERE . में 3 फ़ील्ड का उपयोग करती है क्लॉज, यह पंक्तियों को तेजी से ढूंढेगा।
ALTER TABLE `adverts` ADD INDEX price_status_approved(`price`, `status`, `approved`);
MySQL दस्तावेज़ के अनुसार ऑर्डर बाय ऑप्टिमाइज़ेशन :
आपके मामले में यही होता है। EXPLAIN . के आउटपुट के रूप में हमें बताता है, ऑप्टिमाइज़र कुंजी का उपयोग करता है price पंक्तियों को खोजने के लिए। हालांकि, ORDER BY फ़ील्ड पर है date_updated जो कुंजी price . से संबंधित नहीं है ।
पंक्तियों को तेज़ी से ढूंढने और पंक्तियों को तेज़ी से क्रमबद्ध करने के लिए, आपको एक इंडेक्स जोड़ना होगा जिसमें WHERE में उपयोग किए गए सभी फ़ील्ड शामिल हों और ORDER BY . में खंड:
ALTER TABLE `adverts` ADD INDEX status_approved_date_updated(`status`, `approved`, `date_updated`);
छँटाई के लिए उपयोग किया जाने वाला क्षेत्र सूचकांक में अंतिम स्थान पर होना चाहिए। price को शामिल करना बेकार है अनुक्रमणिका में, क्योंकि क्वेरी में उपयोग की गई शर्त मानों की श्रेणी लौटाएगी।
अगर EXPLAIN अभी भी दिखाता है कि यह फाइलसॉर्ट का उपयोग कर रहा है, आप MySQL को अपने द्वारा चुने गए इंडेक्स का उपयोग करने के लिए मजबूर करने का प्रयास कर सकते हैं:
SELECT adverts.*
FROM adverts
FORCE INDEX(status_approved_date_updated)
WHERE price >= 0
AND adverts.status = 1
AND adverts.approved = 1
ORDER BY date_updated DESC
LIMIT 19990, 10
आमतौर पर किसी इंडेक्स को बाध्य करने की आवश्यकता नहीं होती है, क्योंकि MySQL ऑप्टिमाइज़र अक्सर सही चुनाव करता है। लेकिन कभी-कभी यह एक बुरा चुनाव करता है, या सबसे अच्छा विकल्प नहीं। यह देखने के लिए कि क्या यह प्रदर्शन में सुधार करता है या नहीं, आपको कुछ परीक्षण चलाने की आवश्यकता होगी।
