क्वेरी ऑप्टिमाइज़र ऑपरेटर पसंद - नेस्टेड लूप बनाम हैश मैच (या मर्ज)

बिल्कुल। एक हैश मैच एक बहुत बड़ा सुधार होगा। छोटी 19,223 पंक्ति तालिका पर हैश बनाना और फिर बड़ी 65,991 पंक्ति तालिका के साथ इसकी जांच करना नेस्टेड लूप की तुलना में बहुत छोटा ऑपरेशन है जिसमें 1,268,544,993 पंक्ति तुलना की आवश्यकता होती है।

सर्वर नेस्टेड लूपों को चुनने का एकमात्र कारण यह है कि इसमें शामिल पंक्तियों की संख्या को बुरी तरह से कम करके आंका गया है। क्या आपकी तालिकाओं में उनके आंकड़े हैं, और यदि हां, तो क्या उन्हें नियमित रूप से अपडेट किया जा रहा है? सांख्यिकी वे हैं जो सर्वर को अच्छी निष्पादन योजनाएँ चुनने में सक्षम बनाती हैं।

यदि आपने आँकड़ों को ठीक से संबोधित किया है और अभी भी कोई समस्या हो रही है तो आप इसे HASH जॉइन का उपयोग करने के लिए मजबूर कर सकते हैं:

SELECT *
FROM
   TableA A -- The smaller table
   LEFT HASH JOIN TableB B -- the larger table

कृपया ध्यान दें कि जिस क्षण आप ऐसा करते हैं, यह भी शामिल होने के आदेश को बाध्य करेगा। इसका मतलब है कि आपको अपनी सभी तालिकाओं को सही ढंग से व्यवस्थित करना होगा ताकि उनके शामिल होने का क्रम समझ में आए। आम तौर पर आप सर्वर के पास पहले से मौजूद निष्पादन योजना की जांच करेंगे और मिलान करने के लिए क्वेरी में अपनी तालिकाओं के क्रम को बदल देंगे। यदि आप इसे करने के तरीके से परिचित नहीं हैं, तो मूल बातें यह हैं कि प्रत्येक "बाएं" इनपुट पहले आता है, और ग्राफिकल निष्पादन योजनाओं में, बायां इनपुट निचला होता है। एक। कई तालिकाओं को शामिल करने वाले एक जटिल जुड़ाव को कोष्ठक के अंदर समूह में शामिल होना पड़ सकता है, या RIGHT JOIN का उपयोग करना पड़ सकता है निष्पादन योजना को इष्टतम बनाने के लिए (बाएं और दाएं इनपुट को स्वैप करें, लेकिन तालिका को सम्मिलित क्रम में सही बिंदु पर पेश करें)।

आम तौर पर शामिल होने के संकेतों का उपयोग करने और शामिल होने के आदेश का उपयोग करने से बचने के लिए सबसे अच्छा है, इसलिए जो कुछ भी आप पहले कर सकते हैं वह करें! आप टेबल पर इंडेक्स देख सकते हैं, विखंडन कर सकते हैं, कॉलम के आकार को कम कर सकते हैं (जैसे कि varchar का उपयोग करना) nvarchar . के बजाय जहां यूनिकोड की आवश्यकता नहीं है), या क्वेरी को भागों में विभाजित करना (पहले एक अस्थायी तालिका में डालें, फिर उसमें शामिल हों)।