OR के बजाय संघ का उपयोग करना

कभी-कभी धीमी क्वेरी को थोड़ा संशोधित करके क्वेरी को ठीक किया जा सकता है। ऐसे उदाहरण का उदाहरण तब दिया जा सकता है जब OR या IN ऑपरेटर के उपयोग से WHERE क्लॉज में कई मानों की तुलना की जाती है। अक्सर एक OR इंडेक्स या टेबल स्कैन का कारण बन सकता है, जो कि I / O उपभोग या समग्र क्वेरी गति के मामले में पसंदीदा निष्पादन योजना नहीं हो सकता है।

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

यूनिअन बनाम या

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

यहाँ हमारा OR कथन है:

SELECT SalesOrderID, * FROM sales.SalesOrderDetail WHERE ProductID = 750 OR ProductID = 953 

इस निष्पादन योजना से, हम देखते हैं कि हम 121,000 पंक्तियों को स्कैन कर रहे हैं। (आप पंक्तियों की संख्या नहीं देख सकते, लेकिन यह है)।

अब हम उसी क्वेरी को निष्पादित करते हैं, लेकिन OR के बजाय UNION का उपयोग करते हुए लिखा जाता है:

 SELECT [SalesOrderID], * FROM sales.SalesOrderDetail WHERE ProductID = 750 UNION SELECT [SalesOrderID], * FROM sales.SalesOrderDetail WHERE ProductID = 953 

यहां हम संचालन की दो शाखाएं देखते हैं। एक शाखा 358 लाइनों और दूसरी 346 लाइनों को प्रभावित करती है। दोनों शाखाओं को एक संगति संचालन करने के लिए पाया जाता है जो परिणामों के दोनों सेटों को जोड़ती है। हमारे पास दो अलग-अलग खोजें हैं, लेकिन आवश्यक चयन सूची प्राप्त करने के लिए हमारे पास एक महत्वपूर्ण खोज भी है। स्कैन ऑपरेशन के लिए यह आवश्यक नहीं था, क्योंकि हमने अभी भी स्कैन ऑपरेशन की सभी लाइनों को प्रभावित किया था, इसलिए डेटा स्कैन के दौरान प्राप्त किया गया था, बाद में नहीं। यह सूचकांक और उन पंक्तियों के कारण है जिनकी हमें आवश्यकता है, न कि UNION या OR। हालाँकि, मैं कहूंगा कि खोज बनाम स्कैन चुनने में कारक भी है, लेकिन हम इस लेख में इसे अनदेखा करेंगे।

व्याख्या

क्यों UNION स्कैन के बजाय अधिक खोजों का कारण बनता है, क्योंकि प्रत्येक ऑपरेशन को एक खोज के लिए अर्हता प्राप्त करने के लिए एक निश्चित चयनात्मकता की आवश्यकता को पूरा करना चाहिए। (चयनात्मकता एक विशेष फ़िल्टर्ड कॉलम की विशिष्टता है)। या एक एकल ऑपरेशन में होता है, इसलिए जब प्रत्येक स्तंभ के लिए चयनात्मकता संयुक्त होती है और यह एक निश्चित प्रतिशत से अधिक हो जाती है, तो स्कैनिंग को अधिक कुशल माना जाता है।

चूंकि UNION डिफ़ॉल्ट रूप से प्रत्येक ऑपरेटर के लिए एक अलग ऑपरेशन करता है, इसलिए प्रत्येक कॉलम की चयनात्मकता संयुक्त नहीं होती है, जिससे उसे खोज करने का बेहतर मौका मिलता है। अब, चूंकि UNION दो ऑपरेशन करता है, इसलिए उन्हें ऊपर वर्णित ऑपरेशन ऑपरेशन का उपयोग करके अपने परिणाम सेट से मेल खाना चाहिए। यह आमतौर पर एक महंगा ऑपरेशन नहीं है।

यह भी ध्यान दिया जाना चाहिए कि ओआर क्लॉज IN स्टेटमेंट की तरह ही काम करता है।

आशा है कि यह टिप मदद करेगी। मेरा मानना ​​है कि सिस्टम के साथ काम करते समय यह बहुत मूल्यवान होता है जिसके लिए उच्च संगामिति की आवश्यकता होती है।