बिना जॉइन के Oracle IN क्लॉज के प्रदर्शन निहितार्थ क्या हैं?

यदि आपकी तालिका के आंकड़े सटीक हैं, तो इसकी बहुत कम संभावना होनी चाहिए कि ऑप्टिमाइज़र प्राथमिक कुंजी अनुक्रमणिका का उपयोग करने के बजाय तालिका स्कैन करना चुनें, जब आपके पास WHERE में केवल 1000 हार्ड-कोडेड तत्व हों खंड। सबसे अच्छा तरीका यह होगा कि आप अपनी वस्तुओं पर सटीक आँकड़े इकट्ठा करें (या सेट करें) क्योंकि इससे गलत आँकड़ों के आसपास काम करने के लिए बहुत सारे जिम्नास्टिक करने की कोशिश करने के बजाय अच्छी चीजें अपने आप हो जाएँगी।

यदि हम मानते हैं कि आंकड़े उस हद तक गलत हैं, जिससे ऑप्टिमाइज़र को यह विश्वास हो जाएगा कि प्राथमिक कुंजी इंडेक्स का उपयोग करने की तुलना में एक टेबल स्कैन अधिक कुशल होगा, तो आप संभावित रूप से DYNAMIC_SAMPLING में जोड़ सकते हैं। संकेत जो अनुकूलक को कथन या CARDINALITY को अनुकूलित करने से पहले अधिक सटीक आंकड़े एकत्र करने के लिए बाध्य करेगा अनुकूलक के डिफ़ॉल्ट कार्डिनैलिटी अनुमान को ओवरराइड करने का संकेत। उनमें से किसी को भी उपलब्ध इंडेक्स के बारे में कुछ भी जानने की आवश्यकता नहीं होगी, इसके लिए केवल टेबल उपनाम (या यदि कोई उपनाम नहीं है तो नाम) जानने की आवश्यकता होगी। DYNAMIC_SAMPLING सुरक्षित, अधिक मजबूत दृष्टिकोण होगा लेकिन यह पार्सिंग चरण में समय जोड़ देगा।

यदि आप एक IN . में हार्ड-कोडेड पैरामीटरों की एक चर संख्या के साथ एक SQL स्टेटमेंट बना रहे हैं क्लॉज, आप अपने साझा पूल को गैर-साझा करने योग्य SQL के साथ भरकर और डेटाबेस को प्रत्येक संस्करण को अलग-अलग पार्स करने में बहुत समय बिताने के लिए मजबूर करके अपने लिए प्रदर्शन समस्याएं पैदा करने जा रहे हैं। यह बहुत अधिक कुशल होगा यदि आपने एक एकल साझा करने योग्य SQL कथन बनाया है जिसे एक बार पार्स किया जा सकता है। आपके IN . के आधार पर क्लॉज मान से आ रहे हैं, जो कुछ इस तरह दिख सकते हैं

SELECT *
  FROM table_name
 WHERE primary_key IN (SELECT primary_key
                         FROM global_temporary_table);

या

SELECT *
  FROM table_name
 WHERE primary_key IN (SELECT primary_key
                         FROM TABLE( nested_table ));

या

SELECT *
  FROM table_name
 WHERE primary_key IN (SELECT primary_key
                         FROM some_other_source);

यदि आप अपने आप को एक एकल साझा करने योग्य SQL कथन के लिए नीचे ले गए हैं, तो कथन को लगातार पुन:पार्स करने की लागत से बचने के अलावा, आपके पास एक विशेष योजना को मजबूर करने के लिए कई विकल्प होंगे जिसमें SQL कथन को संशोधित करना शामिल नहीं है। Oracle के विभिन्न संस्करणों में योजना स्थिरता के लिए अलग-अलग विकल्प हैं-- संग्रहीत रूपरेखाएँ हैं , SQL योजना प्रबंधन , और SQL प्रोफ़ाइल आपकी रिलीज़ के आधार पर अन्य तकनीकों के बीच। आप विशेष SQL कथनों के लिए विशेष योजनाओं को बाध्य करने के लिए इनका उपयोग कर सकते हैं। यदि आप नए SQL स्टेटमेंट जेनरेट करते रहते हैं जिन्हें फिर से पार्स करना पड़ता है, हालांकि, इन तकनीकों का उपयोग करना बहुत मुश्किल हो जाता है।