2009-07-29 14 views
126

मेरे पास ऐसा कोई मामला है जहां जॉइन या आईएन का उपयोग करने से मुझे सही परिणाम मिलेंगे ... जो आमतौर पर बेहतर प्रदर्शन करता है और क्यों? यह आपके द्वारा चलाए जा रहे डेटाबेस सर्वर पर कितना निर्भर करता है? (एफवाईआई मैं एमएसएसक्यूएल का उपयोग कर रहा हूं)एसक्यूएल जॉइन बनाम प्रदर्शन में?

+0

संभावित डुप्ले के लिए खेद है ... जब मैं – Polaris878

+0

खोज रहा था तो उस प्रश्न को नहीं मिला :) मैं वास्तव में एक अलग लेख की तलाश में था जब मैंने कुछ समय पहले कुछ शोध किया था, और उस पर ठोकर खाई गलती – AdaTheDev

उत्तर

153

आम तौर पर, IN और JOIN अलग-अलग प्रश्न हैं जो विभिन्न परिणाम प्राप्त कर सकते हैं।

SELECT a.* 
FROM a 
JOIN b 
ON  a.col = b.col 

जब तक b.col अद्वितीय है,

SELECT a.* 
FROM a 
WHERE col IN 
     (
     SELECT col 
     FROM b 
     ) 

के रूप में ही नहीं है।

SELECT a.* 
FROM a 
JOIN (
     SELECT DISTINCT col 
     FROM b 
     ) 
ON  b.col = a.col 

में शामिल होने स्तंभ UNIQUE है और इस तरह के रूप में चिह्नित है, दोनों इन प्रश्नों SQL Server में एक ही योजना उपज हैं:

बहरहाल, यह पहली क्वेरी के लिए पर्याय है।

यदि यह नहीं है, तो INDISTINCT पर JOIN से तेज़ है।

प्रदर्शन जानकारी के लिए अपने ब्लॉग में इस लेख देखें:

+4

ओह, अच्छा प्लग :-) – paxdiablo

+0

हाँ यह समझ में आता है कि अगर वे कॉलिंग कॉलम अद्वितीय है (जो मेरे मामले में है) – Polaris878

+1

इसी तरह के नोट पर, मैं इन (चयन DISTINCT ...) का उपयोग करना चाहिए या बस में (चुनें ...)? – moo

3

यह कहना मुश्किल है - वास्तव में यह पता लगाने के लिए कि कौन सा बेहतर काम करता है, आपको वास्तव में निष्पादन समयों को प्रोफ़ाइल करना होगा।

अंगूठे के सामान्य नियम के रूप में, मुझे लगता है कि अगर आपके पास अपने विदेशी कुंजी कॉलम पर इंडेक्स हैं, और यदि आप केवल (या अधिकतर) इनर जॉइन स्थितियों का उपयोग कर रहे हैं, तो जॉइन थोड़ा तेज होगा।

लेकिन जैसे ही आप बाहरी जॉइन का उपयोग शुरू करते हैं, या यदि आप विदेशी कुंजी इंडेक्स की कमी कर रहे हैं, तो आईएन जल्दी हो सकता है।

मार्क

+0

मैं यह भी सोच रहा था ... क्योंकि ऐसा लगता है कि जॉइन एक आम मामला है और अधिक संभावना – Polaris878

23

अजीब बात है आप का उल्लेख है कि, मैं इस बहुत विषय पर एक ब्लॉग पोस्ट किया था।

देखें Oracle vs MySQL vs SQL Server: Aggregation vs Joins

लघु जवाब: आप इसे परीक्षण करने के लिए है और अलग-अलग डेटाबेस एक बहुत भिन्नता है।

+3

ओहह अनुकूलित किया जाएगा, एक और अच्छा प्लग :-) – paxdiablo

+2

मैं आत्म-प्रचार से ऊपर नहीं हूं। :) – cletus

+2

@cletus: मैं वास्तव में इन-बनाम-जॉइन-बनाम-मौजूद डॉट कॉम में पंजीकरण करने के लिए प्रेरित हूं, सभी प्लग इकट्ठा करता हूं और धन इकट्ठा करना शुरू करता हूं: – Quassnoi

1

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

+3

क्या करना चाहिए? शायद। क्या यह? नहीं, मेरी पोस्ट देखें। – cletus

3

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

मुझे यकीन नहीं है कि आप जिस एमएसएसक्यूएल का उपयोग कर रहे हैं उसका संस्करण क्या है लेकिन आप क्वेरी विश्लेषक में SQL Server 2000 में आलेखीय प्राप्त कर सकते हैं। मुझे यकीन है कि यह कार्यक्षमता कुछ संस्करणों को गुप्त कर रही है जहां बाद के संस्करणों में SQL सर्वर स्टूडियो प्रबंधक में।

बहिष्करण योजना पर एक नज़र डालें। जहां तक ​​संभव हो, टेबल स्कैन से बचें जब तक कि आपकी तालिका छोटी न हो, इस स्थिति में एक तालिका स्कैन एक इंडेक्स का उपयोग करने से तेज है। विभिन्न अलग-अलग परिचालनों पर पढ़ें जो प्रत्येक अलग-अलग परिदृश्य उत्पन्न करते हैं।

3

तार्किक मतभेद के बारे में एक दिलचस्प writeup: SQL Server: JOIN vs IN vs EXISTS - the logical difference

मैं बहुत यकीन है कि यह सोचते हैं कि संबंधों और इंडेक्स बनाए रखा जाता है एक जॉइन बेहतर समग्र प्रदर्शन करेगा (उस प्रयास के साथ काम करने में अधिक प्रयास करता है)। यदि आप इसके बारे में अवधारणा के बारे में सोचते हैं तो यह 2 प्रश्नों और 1 क्वेरी के बीच का अंतर है।

आपको इसे क्वेरी विश्लेषक तक हुक करने की आवश्यकता है और इसे आजमाएं और अंतर देखें। क्वेरी निष्पादन योजना को भी देखें और चरणों को कम करने का प्रयास करें।

+0

दिलचस्प ..... –

+0

मेरे लिए सबसे अच्छा जवाब –

2

यह थ्रेड बहुत पुराना है लेकिन अभी भी अक्सर उल्लेख किया गया है। मेरे व्यक्तिगत स्वाद के लिए यह थोड़ा अपूर्ण है, क्योंकि डेटाबेस को EXISTS कीवर्ड के साथ पूछने का एक और तरीका है जिसे मैंने अधिक तेज़ी से नहीं पाया है।

तो तुम केवल तालिका से मूल्यों में रुचि एक तो आप इस क्वेरी का उपयोग कर सकते हैं:

SELECT a.* 
FROM a 
WHERE EXISTS (
    SELECT * 
    FROM b 
    WHERE b.col = a.col 
    ) 

अंतर बहुत बड़ा है, तो col अनुक्रमित नहीं है हो सकता है, क्योंकि DB में सभी रिकॉर्ड को खोजने के लिए नहीं है बी जिसमें कॉल में समान मूल्य है, इसे केवल पहले ही ढूंढना है। यदि b.col पर कोई अनुक्रमणिका नहीं है और तालिका स्कैन में बहुत से रिकॉर्ड परिणाम हो सकते हैं। इन या जॉइन के साथ यह एक पूर्ण टेबल स्कैन होगा, EXISTS के साथ यह केवल आंशिक तालिका स्कैन होगा (जब तक कि पहला मिलान रिकॉर्ड नहीं मिलता)।

यदि बी में बहुत सारे रिकॉर्ड्स हैं जिनमें एक ही कॉल वैल्यू है तो आप इन सभी रिकॉर्ड्स को अस्थायी जगह में पढ़ने के लिए बहुत सारी मेमोरी बर्बाद कर देंगे ताकि यह पता चल सके कि आपकी हालत संतुष्ट है। अस्तित्व में यह आमतौर पर टाला जा सकता है।

मुझे अक्सर इंडेक्स तेजी से मिलते हैं, भले ही कोई अनुक्रमणिका हो। यह डेटाबेस सिस्टम (ऑप्टिमाइज़र) पर निर्भर करता है, डेटा और कम से कम इंडेक्स के प्रकार पर उपयोग नहीं किया जाता है।

+2

एमएसएसक्ल पर तथ्य यह है कि एक आईएन से बेहतर है, यह सच नहीं है। अधिक जानकारी के लिए: http://explainextended.com/2009/06/16/in-vs-join-vs-exists/ यहां पर आप इसे पढ़ सकते हैं: "बहुत से लोग सोचते हैं कि EXISTS अधिक कुशल है, क्योंकि EXISTS केवल एक पंक्ति देता है। यह SQL सर्वर के लिए सच नहीं है। जैसा कि हम ऊपर दिए गए उदाहरणों से देख सकते हैं, EXISTS और IN एक ही योजनाएं उत्पन्न करता है। ऐसा इसलिए है क्योंकि EXISTS IN से अधिक लचीला है। EXISTS के रूप में पुनः लिखा गया (एक equijoin के साथ एक साधारण WHERE स्थिति का उपयोग कर) लेकिन इसके विपरीत नहीं। " –

संबंधित मुद्दे