MySQL में ज्ञात समस्याएं हैं सहसंबद्ध उपश्रेणियों, या उप-चयनों से संबंधित प्रश्नों को अनुकूलित करने के साथ। संस्करण 5.6.5 तक यह उपश्रेणियों को अमल में नहीं लाता है, हालांकि यह एक व्युत्पन्न तालिका में शामिल हो जाएगा।
संक्षेप में इसका मतलब यह है कि जब आप किसी जॉइन का उपयोग करते हैं, तो पहली बार सबक्वेरी का सामना करने पर MySQL निम्नलिखित कार्य करेगा:
SELECT code1 FROM myTable GROUP BY code1 HAVING COUNT(code1) > 1
और परिणामों को एक अस्थायी तालिका में रखें (जिसे लुकअप को तेज़ बनाने के लिए हैश किया गया है), फिर myTable में प्रत्येक मान के लिए यह देखने के लिए कि क्या कोड है या नहीं, यह अस्थायी तालिका के सामने खोजेगा।
हालाँकि, जब से आप IN . का उपयोग करते हैं सबक्वेरी को अमल में नहीं लाया गया है और इसे फिर से लिखा गया है:
SELECT t1.code1, t1.code2
FROM myTable t1
WHERE EXISTS
( SELECT t2.code1
FROM myTable t2
WHERE t2.Code1 = t1.Code1
GROUP BY t2.code1
HAVING COUNT(t2.code1) > 1
)
जिसका अर्थ है कि प्रत्येक code . के लिए myTable . में , यह सबक्वेरी फिर से चलाता है। जब आपकी बाहरी क्वेरी बहुत संकीर्ण होती है, तो ठीक है, क्योंकि यह केवल कुछ ही बार सबक्वेरी चलाने के लिए अधिक कुशल है, इसे सभी मानों के लिए चलाने और परिणामों को अस्थायी तालिका में संग्रहीत करने के लिए, हालांकि जब आपकी बाहरी क्वेरी विस्तृत होती है, तो इसका परिणाम होता है कई बार निष्पादित आंतरिक क्वेरी में, और यही वह जगह है जहां प्रदर्शन अंतर शुरू होता है।
तो आपकी पंक्ति गणना के लिए, सबक्वेरी को ~30,000 बार चलाने के बजाय, आप इसे एक बार चलाते हैं, फिर हैशेड अस्थायी तालिका के विरुद्ध ~ 30,000 पंक्तियों को केवल 400 पंक्तियों के साथ देखें। यह इस तरह के एक कठोर प्रदर्शन अंतर के लिए जिम्मेदार होगा।
ऑनलाइन डॉक्स में यह लेख सबक्वेरी ऑप्टिमाइज़ेशन को और अधिक गहराई से समझाता है।
