बिटमैप फ़िल्टर के साथ क्वेरी योजना कभी-कभी पढ़ने के लिए मुश्किल हो सकती है। प्रजनन धाराओं (जोर मेरा) के लिए BOL लेख से :
रेपिशन स्ट्रीम्स ऑपरेटर कई धाराओं का उपभोग करता है और रिकॉर्ड की कई धाराओं का उत्पादन करता है। रिकॉर्ड सामग्री और प्रारूप नहीं बदले गए हैं। यदि क्वेरी ऑप्टिमाइज़र एक बिटमैप फ़िल्टर का उपयोग करता है, तो आउटपुट स्ट्रीम में पंक्तियों की संख्या कम हो जाती है।
इसके अलावा, बिटमैप फ़िल्टर पर एक लेख भी उपयोगी है:
बिटमैप फ़िल्टरिंग वाले निष्पादन योजना का विश्लेषण करते समय, यह समझना महत्वपूर्ण है कि डेटा योजना के माध्यम से कैसे बहता है और फ़िल्टरिंग कहां लागू होता है। बिटमैप फ़िल्टर और अनुकूलित बिटमैप हैश ज्वाइंट के बिल्ड इनपुट (आयाम तालिका) पर बनाया गया है; हालाँकि, वास्तविक फ़िल्टरिंग आमतौर पर Parallelism ऑपरेटर के भीतर किया जाता है, जो हैश ज्वाइन के जांच इनपुट (तथ्य तालिका) पक्ष पर होता है। हालाँकि, जब बिटमैप फ़िल्टर पूर्णांक स्तंभ पर आधारित होता है, तो फ़िल्टर समानांतर तालिका ऑपरेटर के बजाय प्रारंभिक तालिका या अनुक्रमणिका स्कैन ऑपरेशन पर सीधे लागू किया जा सकता है। इस तकनीक को इन-पंक्ति अनुकूलन कहा जाता है।
मुझे विश्वास है कि आप अपनी क्वेरी का अवलोकन कर रहे हैं। बिटमैप के ऑपरेटर IN_ROWतथ्य तालिका के खिलाफ होते हुए भी, कार्डियॉलिटी अनुमान को कम करने वाले एक रिपर्टिशन स्ट्रीम ऑपरेटर को दिखाने के लिए अपेक्षाकृत सरल डेमो के साथ आना संभव है । डेटा प्रस्तुत करने का:
create table outer_tbl (ID BIGINT NOT NULL);
INSERT INTO outer_tbl WITH (TABLOCK)
SELECT TOP (1000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values;
create table inner_tbl_1 (ID BIGINT NULL);
create table inner_tbl_2 (ID BIGINT NULL);
INSERT INTO inner_tbl_1 WITH (TABLOCK)
SELECT (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) / 2000000 - 2) NUM
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;
INSERT INTO inner_tbl_2 WITH (TABLOCK)
SELECT (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) / 2000000 - 2) NUM
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;
यहाँ एक क्वेरी है जिसे आपको नहीं चलाना चाहिए:
SELECT *
FROM outer_tbl o
INNER JOIN inner_tbl_1 i ON o.ID = i.ID
INNER JOIN inner_tbl_2 i2 ON o.ID = i2.ID
OPTION (HASH JOIN, QUERYTRACEON 9481, QUERYTRACEON 8649);
मैंने योजना अपलोड की । पास के ऑपरेटर पर एक नज़र डालें inner_tbl_2:
आप पाॅल व्हाइट सहायक द्वारा हैश जॉन्स इन नुल्लेबल कॉलम पर दूसरा टेस्ट भी पा सकते हैं ।
पंक्ति में कमी कैसे लागू की जाती है, इसमें कुछ विसंगतियां हैं। मैं केवल कम से कम तीन तालिकाओं वाली योजना में इसे देख पा रहा था। हालाँकि, सही डेटा वितरण के साथ अपेक्षित पंक्तियों में कमी उचित लगती है। मान लीजिए कि तथ्य तालिका में शामिल स्तंभ में कई दोहराए गए मान हैं जो आयाम तालिका में मौजूद नहीं हैं। बिटमैप फ़िल्टर शामिल होने से पहले उन पंक्तियों को समाप्त कर सकता है। आपकी क्वेरी के लिए अनुमान सभी तरह से घटाया जाता है। 1. हैश फ़ंक्शन के बीच पंक्तियों को कैसे वितरित किया जाता है, एक अच्छा संकेत प्रदान करता है:
इसके आधार पर मुझे संदेह है कि आपके पास Object1.Column21कॉलम के लिए बहुत बार दोहराया गया मूल्य है । यदि दोहराए गए कॉलम आंकड़े हिस्टोग्राम में नहीं होते हैं, Object4.Column19तो SQL सर्वर कार्डिनैलिटी का अनुमान बहुत गलत हो सकता है।
मुझे लगता है कि आपको इस बात से चिंतित होना चाहिए कि क्वेरी के प्रदर्शन में सुधार करना संभव हो सकता है। बेशक, अगर क्वेरी प्रतिक्रिया समय या एसएलए आवश्यकताओं को पूरा करती है तो यह आगे की जांच के लायक नहीं हो सकती है। हालाँकि, यदि आप आगे की पड़ताल करना चाहते हैं, तो कुछ चीजें हैं जो आप कर सकते हैं (आँकड़े अद्यतन करने के अलावा) इस पर विचार प्राप्त करने के लिए कि क्या क्वेरी ऑप्टिमाइज़र एक बेहतर योजना चुन लेगा, अगर उसके पास बेहतर जानकारी हो। के बीच में शामिल होने आप परिणामों डाल सकता है Database1.Schema1.Object10और Database1.Schema1.Object11एक अस्थायी तालिका में है और यदि आप नेस्टेड लूप मिलती मिलना जारी रहता है देखते हैं। आप बदल सकते हैं LEFT OUTER JOINताकि क्वेरी ऑप्टिमाइज़र उस चरण में पंक्तियों की संख्या कम न कर सके। आप MAXDOP 1अपनी क्वेरी में यह देखने के लिए एक संकेत जोड़ सकते हैं कि क्या होता है। आप उपयोग कर सकते हैंTOPअंतिम में शामिल होने के लिए बाध्य करने के लिए एक व्युत्पन्न तालिका के साथ, या आप क्वेरी से जुड़ने की टिप्पणी भी कर सकते हैं। उम्मीद है कि ये सुझाव आपको आरंभ करने के लिए पर्याप्त हैं।
प्रश्न में कनेक्ट आइटम के बारे में , यह बहुत संभावना नहीं है कि यह आपके प्रश्न से संबंधित है। यह समस्या खराब रो अनुमान के साथ नहीं है। यह समानता में एक दौड़ की स्थिति के साथ करना है जो पर्दे के पीछे क्वेरी योजना में बहुत अधिक पंक्तियों को संसाधित करने का कारण बनता है। यहाँ ऐसा लगता है कि आपकी क्वेरी कोई अतिरिक्त काम नहीं कर रही है।
