InnoDB में, किसी भी द्वितीयक अनुक्रमणिका में आंतरिक रूप से तालिका का प्राथमिक कुंजी स्तंभ होता है। तो अनुक्रमणिका नाम कॉलम (नाम) पर कॉलम (नाम, आईडी) पर निहित है।
इसका मतलब है कि EXPLAIN श्रेणी तालिका में आपकी पहुंच को "इंडेक्स-स्कैन" के रूप में दिखाता है (यह प्रकार में दिखाया गया है) कॉलम "इंडेक्स" के रूप में)। अनुक्रमणिका को स्कैन करके, उसके पास आईडी कॉलम तक भी पहुंच होती है, जिसका उपयोग वह दूसरी तालिका, आइटम में पंक्तियों को देखने के लिए करता है।
फिर यह (category_id) पर आइटम इंडेक्स का भी लाभ उठाता है जो वास्तव में (category_id, id) है, और यह केवल इंडेक्स को पढ़कर आपकी चयन-सूची के लिए item.id लाने में सक्षम है। तालिका को बिल्कुल भी पढ़ने की आवश्यकता नहीं है (यह अतिरिक्त . में दिखाया गया है कॉलम "इंडेक्स का उपयोग करना") के रूप में।
MyISAM इस तरह से प्राथमिक कुंजी को द्वितीयक कुंजी के साथ संग्रहीत नहीं करता है, इसलिए इसे समान अनुकूलन नहीं मिल सकता है। श्रेणी तालिका तक पहुंच "ALL" प्रकार है जिसका अर्थ है तालिका-स्कैन।
मैं उम्मीद करता हूं कि माईसाम टेबल आइटम तक पहुंच "रेफरी" होगी क्योंकि यह इंडेक्स (श्रेणी_आईडी) का उपयोग करके पंक्तियों को देखता है। लेकिन ऑप्टिमाइज़र को विषम परिणाम मिल सकते हैं यदि आपके पास तालिका में बहुत कम पंक्तियाँ हैं, या यदि आपने ANALYZE TABLE item अनुक्रमणिका बनाने के बाद से।
अपना अपडेट दें:
ऐसा लगता है कि ऑप्टिमाइज़र टेबल-स्कैन पर इंडेक्स-स्कैन को प्राथमिकता देता है, इसलिए यह InnoDB में इंडेक्स-स्कैन करने का अवसर लेता है, और श्रेणी तालिका को पहले रखता है। ऑप्टिमाइज़र तालिकाओं का उपयोग करने के बजाय तालिकाओं को आपके द्वारा अपनी क्वेरी में दिए गए क्रम में पुन:क्रमित करने का निर्णय लेता है।
MyISAM तालिकाओं में, एक तालिका-स्कैन होगी, जो भी तालिका पहले एक्सेस करने के लिए चुनती है, लेकिन श्रेणी तालिका को दूसरे स्थान पर रखने से, यह आइटम की द्वितीयक अनुक्रमणिका के बजाय श्रेणी की प्राथमिक कुंजी अनुक्रमणिका में शामिल हो जाती है। अनुकूलक एक अद्वितीय या प्राथमिक कुंजी ("eq_ref" टाइप करें) के लुकअप को प्राथमिकता देता है।
