ऐसे ही चीजें चलती हैं। एक मिनट मेरे साथ रहो...
अनुकूलक एक INDEX का उपयोग करना चाहेगा, इस स्थिति में ACTI_DATE_I. लेकिन अगर यह धीमा होगा तो वह इसका उपयोग नहीं करना चाहता।
योजना ए:सूचकांक का प्रयोग करें।
- बीट्री-स्ट्रक्चर्ड इंडेक्स में अंत में पहुंचें (डीईएससी की वजह से)
- पीछे स्कैन करें
- सूचकांक में प्रत्येक पंक्ति के लिए, डेटा में संगत पंक्ति देखें। नोट:अनुक्रमणिका में (ACTIVITY_DATE, ACTIVITY_ID) है क्योंकि प्राथमिक कुंजी किसी भी द्वितीयक कुंजी में निहित रूप से संलग्न है। पीके (ACTIVITY_ID) का उपयोग करके "डेटा" तक पहुंचने के लिए एक और बीट्री लुकअप है, संभावित रूप से यादृच्छिक। इसलिए, यह संभावित रूप से धीमा है। (लेकिन आपके मामले में बहुत धीमा नहीं है।)
- यह LIMIT पंक्तियों के बाद रुक जाता है।
प्लान बी:टेबल पर ध्यान न दें
- टीएमपी टेबल बनाकर टेबल को स्कैन करें। (स्मृति में होने की संभावना है।)
- tmp तालिका क्रमित करें
- LIMIT पंक्तियों को हटा दें।
आपके मामले में (96 - 10K का 1%) यह आश्चर्यजनक है कि इसने टेबल स्कैन को चुना। आम तौर पर, कटऑफ तालिका में पंक्तियों की संख्या का लगभग 10% -30% होता है।
ANALYZE TABLE चाहिए आँकड़ों की पुनर्गणना का कारण बना है, जो सकता इसे दूसरी योजना के साथ जाने के लिए राजी कर लिया है।
आप MySQL का किस संस्करण का उपयोग कर रहे हैं? (नहीं, मुझे इस क्षेत्र में किसी बदलाव की जानकारी नहीं है।)
एक चीज जिसे आप आजमा सकते हैं:OPTIMIZE TABLE ACTIVITIES; यह तालिका का पुनर्निर्माण करेगा, जिससे ब्लॉकों को दोबारा पैक किया जाएगा और संभावित रूप से . की ओर अग्रसर किया जाएगा विभिन्न आँकड़े। अगर इससे मदद मिलती है, तो मैं इसे जानना चाहूंगा -- क्योंकि मैं आमतौर पर कहता हूं कि "ऑप्टिमाइज़ टेबल बेकार है"।
