ठीक है - मैं कोशिश करूँगा, यह ज्यादातर उपलब्ध जानकारी से कटौती है:
Oracle एक अलग निष्पादन योजना क्यों चुनता है?
ऐसा लगता है कि आपकी दूसरी क्वेरी में असामान्य दिनांक-प्रारूप के साथ, अनुकूलक को पता नहीं है कि परिणामी तिथि का मूल्य क्या है। आप फ़िल्टर विधेय देखें:
1 - filter(TO_DATE('20140610 ','yyyymmdd ')<=TO_DATE(' 2014-06-10 23:59:59', 'syyyy-mm-dd hh24:mi:ss'))
जिसका अर्थ है कि अनुकूलक यह भी सुनिश्चित नहीं है कि पहली तारीख दूसरी से छोटी है! इसका मतलब है कि ऑप्टिमाइज़र को लौटाई गई पंक्तियों की संख्या के बारे में कोई जानकारी नहीं है और विशिष्ट आंकड़ों को ध्यान में रखे बिना केवल एक सामान्य योजना का उपयोग करेगा। यह वही होगा यदि आपके पास उपयोगकर्ता द्वारा परिभाषित फ़ंक्शन xyt() था जो सीमा के लिए एक तिथि लौटाएगा। ऑप्टिमाइज़र के पास यह जानने का कोई तरीका नहीं है कि दिनांक-मान का परिणाम क्या होगा - इसका मतलब है कि आपको एक सामान्य सर्व-उद्देश्यीय योजना मिलती है, जो किसी भी निर्दिष्ट दिनांक-सीमा के लिए बहुत अच्छी होनी चाहिए।
पहले और तीसरे मामले में, अनुकूलक सीधे तारीख को समझता है और आंकड़ों का उपयोग करके दिनांक सीमा में पंक्तियों की संख्या का अनुमान लगा सकता है। तो जबकि दूसरी क्वेरी ऑप्टिमाइज़र के लिए थी जैसे BETWEEN X AND 3 यह क्वेरी BETWEEN 1 AND 3 . जैसी है इसलिए वह लौटाई गई पंक्तियों की अनुमानित संख्या के लिए क्वेरी योजना को अनुकूलित करता है!
अजीब बात यह प्रतीत होती है, कि क्वेरी ऑप्टिमाइज़र में एक अजीब दिनांक प्रारूप के साथ ऐसी समस्याएं हैं, जिसे बग/सुधार के लिए अनुरोध के रूप में दायर किया जा सकता है...
लेकिन एक महत्वपूर्ण बिंदु:
- एक पूर्ण तालिका स्कैन के लिए एक खराब योजना होना जरूरी नहीं है... साथ ही एक अनुक्रमणिका का उपयोग करना हमेशा तेज़ नहीं होता है!
- क्वेरी प्लान में लागत किसी भी तरह से वास्तविक निष्पादन समय या प्रदर्शन से सीधे संबंधित नहीं है - यह समान क्वेरी के लिए विभिन्न योजनाओं की तुलना करने के लिए एक आंतरिक माप है (इसलिए आप अपने प्रश्नों की तरह विभिन्न प्रश्नों की लागत की तुलना नहीं कर सकते हैं 1 ,2 और 3)
मूल रूप से यदि आप किसी तालिका से पंक्तियों की एक बड़ी संख्या लौटाते हैं तो अनुक्रमणिका पहुंच के बिना एक पूर्ण तालिका स्कैन कई मामलों में बहुत तेज़ होगा, खासकर जब कुछ विभाजनों पर काम कर रहा हो! - तालिका स्कैन केवल मिलान तिथि सीमा के लिए गड़बड़ी तक पहुंचेगा - इसलिए केवल विचाराधीन तिथि के लिए और इस विभाजन से सभी पंक्तियों को लौटाता है। यह प्रत्येक एकल पंक्ति के लिए अनुक्रमणिका को क्वेरी करने और फिर अनुक्रमणिका पहुँच द्वारा पंक्ति निकालने की तुलना में बहुत तेज़ है... क्वेरी को प्रोफ़ाइल करने का प्रयास करें - विभाजन पर पूर्ण तालिका स्कैन बहुत कम IO के साथ 3 गुना तेज़ होना चाहिए
