(जैसा कि निर्देश दिया गया है, मैं अपनी टिप्पणी का हिस्सा उत्तर में डाल रहा हूं क्योंकि इससे समस्या हल हो गई है)
EXISTS एक्सप्रेशन को IN एक्सप्रेशन में बदलें।
यह इस उदाहरण में बेहतर काम करता है क्योंकि क्वेरी का अब "अंदर से बाहर" से प्रभावी ढंग से मूल्यांकन किया जाएगा, जो उस क्वेरी से शुरू होता है जिसमें आपका सबसे सीमित कारक होता है:पूर्ण टेक्स्ट खोज लुकअप। वह क्वेरी पंक्तियों के एक छोटे से सेट को वापस करने जा रही है जिसे बाहरी क्वेरी की प्राथमिक कुंजी के विरुद्ध सीधे देखा जा सकता है (जहां x in (SELECT X...)) प्रति मान एक बार "आंतरिक" क्वेरी को कॉल करने के विरोध में बाहरी क्वेरी (या आपके मूल मामले में सभी मानों के लिए, यदि मैं इसे सही तरीके से पढ़ रहा हूं)। यहां EXISTS विधि का परिणाम नेस्टेड लूप्स (दूसरे में प्रत्येक मान के लिए एक क्वेरी का एक मूल्यांकन) बनाम IN विधि में हैश जॉइन (कई में अधिक कुशल निष्पादन विधि, यदि अधिकांश नहीं, तो मामलों में होता है।
ध्यान दें कि EXISTS पद्धति के साथ, चार नेस्टेड लूप हैं जो कम से कम 3,000 बार चलने के साथ निष्पादित होते हैं। वह लागत बढ़ जाती है। हालांकि यह प्रत्यक्ष तुलना नहीं है, आप नेस्टेड लूप्स का इलाज कर सकते हैं जैसे आप एप्लिकेशन कोड में लूप के लिए करेंगे:हर बार जब आप एक आंतरिक लूप का आह्वान करते हैं, तो आपका बड़ा-ओ अनुमान परिमाण के क्रम में जाता है:ओ (एन) से ओ (एन ^ 2) से O(n^3), आदि।
हैश जॉइन एक नक्शे की तरह है, जहां एक ही समय में दो सरणियों को आगे बढ़ाया जाता है और दोनों पर एक ऑपरेशन किया जाता है। यह मोटे तौर पर रैखिक है (ओ (एन))। इन्हें योगात्मक के रूप में नेस्टेड होने के बारे में सोचें ताकि यह O(n) से O(2n) से O(3n), आदि तक जाए।
हाँ, हाँ, मुझे पता है कि यह बिल्कुल एक जैसा नहीं है, लेकिन मुद्दा यह है कि कई नेस्टेड लूप होना आमतौर पर एक धीमी क्वेरी योजना को इंगित करता है और दो बड़े-ओ शैली की तुलना करने से इसे पहचानना आसान हो जाता है, मुझे विश्वास है। उन्हें>
नेस्टेड लूप्स और EXISTS, बुराई नहीं हैं, लेकिन ज्यादातर मामलों में जहां एक आधार फ़िल्टर स्थिति होती है जो अंततः सब कुछ प्रभावित करती है (उदाहरण के लिए, प्रश्न में पूर्ण पाठ खोज), एक IN अभिव्यक्ति (या, कुछ में मामलों में, एक उचित जॉइन) एक अधिक कुशल योजना प्रदान करता है।
