क्या एक दृश्य एक साधारण प्रश्न से तेज है?


359

एक है

select *  from myView

दृश्य बनाने के लिए क्वेरी से अधिक तेज़ (समान परिणाम पाने के लिए):

select * from ([query to create same resultSet as myView])

?

यह मेरे लिए पूरी तरह से स्पष्ट नहीं है अगर दृश्य एक साधारण क्वेरी की तुलना में इसे तेजी से बनाने वाली कैशिंग का उपयोग करता है।


7
Iam एक दृश्य के बारे में निश्चित नहीं है, लेकिन नेस्टेड विचार कुल प्रदर्शन नरक है।
मुफ्लिक्स

जवाबों:


680

हां , विचारों में एक संकुल सूचकांक दिया जा सकता है और जब वे करते हैं, तो वे अस्थायी परिणाम संग्रहीत करेंगे जो परिणामस्वरूप प्रश्नों को गति दे सकते हैं।

अपडेट: इस एक पर कम से कम तीन लोगों ने मुझे वोट दिया है। पूरे सम्मान के साथ, मुझे लगता है कि वे सिर्फ गलत हैं; Microsoft के स्वयं के प्रलेखन से यह स्पष्ट हो जाता है कि दृश्य प्रदर्शन में सुधार कर सकते हैं।

सबसे पहले, सरल विचारों को जगह में विस्तारित किया जाता है और इसलिए प्रदर्शन सुधार में सीधे योगदान नहीं करते हैं - यह बहुत सच है। हालांकि, अनुक्रमित विचार नाटकीय रूप से प्रदर्शन में सुधार कर सकते हैं ।

मुझे सीधे दस्तावेज पर जाने दें:

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

दूसरा, ये अनुक्रमित विचार तब भी काम कर सकते हैं जब उन्हें सीधे किसी अन्य क्वेरी द्वारा संदर्भित नहीं किया जाता है क्योंकि उपयुक्त होने पर अनुकूलक उनका उपयोग तालिका संदर्भ के स्थान पर करेगा।

फिर, प्रलेखन:

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

यह प्रलेखन, साथ ही साथ प्रदर्शन सुधारों को प्रदर्शित करने वाले चार्ट यहां देखे जा सकते हैं

अद्यतन 2: उत्तर की आलोचना इस आधार पर की गई है कि यह "सूचकांक" है जो प्रदर्शन लाभ प्रदान करता है, न कि "दृश्य।" हालांकि, यह आसानी से मना कर दिया जाता है।

हम कहते हैं कि हम एक छोटे से देश में एक सॉफ्टवेयर कंपनी हैं; मैं उदाहरण के तौर पर लिथुआनिया का उपयोग करूंगा। हम दुनिया भर में सॉफ्टवेयर बेचते हैं और अपने रिकॉर्ड को SQL सर्वर डेटाबेस में रखते हैं। हम बहुत सफल रहे हैं और इसलिए, कुछ वर्षों में, हमारे पास 1,000,000+ रिकॉर्ड हैं। हालाँकि, हमें अक्सर कर उद्देश्यों के लिए बिक्री की रिपोर्ट करने की आवश्यकता होती है और हम पाते हैं कि हमने अपने सॉफ़्टवेयर की केवल 100 प्रतियां हमारे देश में बेची हैं। केवल लिथुआनियाई अभिलेखों का अनुक्रमित दृश्य बनाकर, हम एमएस प्रलेखन में वर्णित रिकॉर्डों को अनुक्रमित कैश में रखने की आवश्यकता पाते हैं। जब हम 2008 में लिथुआनियाई बिक्री के लिए अपनी रिपोर्ट चलाते हैं, तो हमारी क्वेरी केवल 7 की गहराई (कुछ अप्रयुक्त पत्तियों के साथ Log2 (100)) के साथ एक सूचकांक के माध्यम से खोज करेगी। यदि हम VIEW के बिना भी ऐसा ही कर रहे थे और सिर्फ एक इंडेक्स को टेबल पर निर्भर कर रहे थे, तो हमें 21 के सर्च डेप्थ के साथ एक इंडेक्स ट्री का पता लगाना होगा!

स्पष्ट रूप से, दृश्य स्वयं ही हमें सूचकांक के सरल उपयोग पर प्रदर्शन लाभ (3x) प्रदान करेगा। मैंने एक वास्तविक दुनिया उदाहरण का उपयोग करने की कोशिश की है, लेकिन आप ध्यान देंगे कि लिथुआनियाई बिक्री की एक सरल सूची हमें और भी अधिक लाभ देगी।

ध्यान दें कि मैं अपने उदाहरण के लिए सीधे बी-ट्री का उपयोग कर रहा हूं। जब मैं काफी निश्चित हूं कि एसक्यूएल सर्वर एक बी-ट्री के कुछ प्रकार का उपयोग करता है, तो मुझे इसका विवरण नहीं पता है। बहरहाल, बिंदु रखती है।

अद्यतन 3: यह सवाल सामने आया है कि क्या एक अनुक्रमणित दृश्य केवल अंतर्निहित तालिका पर रखे एक सूचकांक का उपयोग करता है। यही है, पैराफेरेस के लिए: "एक अनुक्रमित दृश्य सिर्फ एक मानक सूचकांक के बराबर है और यह एक दृश्य के लिए नया या आसान कुछ भी नहीं प्रदान करता है।" अगर यह सच था, तो उपरोक्त विश्लेषण गलत होगा! मुझे Microsoft दस्तावेज़ से एक उद्धरण प्रदान करें जो प्रदर्शित करता है कि मुझे लगता है कि यह आलोचना वैध या सत्य नहीं है:

क्वेरी प्रदर्शन को बेहतर बनाने के लिए अनुक्रमित का उपयोग करना एक नई अवधारणा नहीं है; हालाँकि, अनुक्रमित दृश्य अतिरिक्त प्रदर्शन लाभ प्रदान करते हैं जो मानक अनुक्रमित का उपयोग करके प्राप्त नहीं किया जा सकता है।

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


29
हां, अनुक्रमित विचार नाटकीय रूप से प्रदर्शन में सुधार कर सकते हैं। लेकिन अनुक्रमित विचार केवल "दृश्य" नहीं हैं, और आम तौर पर बोलना, सामान्य "दृश्य" उनके संबंधित प्रश्नों से तेज नहीं हैं।
१५:

10
@Charles - अगर यह सूचकांक है, तो कोई फर्क नहीं पड़ता, तथ्य यह है कि एक दृश्य सूचकांक का लाभ उठा सकता है और एक कच्ची क्वेरी पर्याप्त नहीं हो सकती है
annakata


17
ओह, यार, मैंने इस पर 8 डाउनवोट प्राप्त किए हैं! मुझे आश्चर्य है कि लोग अपनी बात पर बहस करने के लिए कम से कम चार्ल्स की हिम्मत के बिना इतनी जल्दी नीचे गिर जाएंगे।
मार्क ब्रिटिंगम

8
चूँकि एक तालिका में केवल एक क्लस्टर इंडेक्स हो सकता है, और आप एक दृश्य पर एक अलग क्लस्टर इंडेक्स बना सकते हैं, (क्योंकि क्लस्टर इंडेक्स में फ़ील्ड इंडेक्स पेजों में स्वतंत्र रूप से बनी रहती हैं), यह एक धोखा है (वर्क-अरंड?) कि आपको एक तालिका पर दो गुच्छेदार सूचकांक प्राप्त करने की अनुमति देता है।
चार्ल्स ब्रेटाना

51

सामान्यतया, नहीं। दृश्य मुख्य रूप से सुविधा और सुरक्षा के लिए उपयोग किए जाते हैं, और वे (स्वयं के द्वारा) कोई गति लाभ नहीं देते हैं।

उस ने कहा, SQL Server 2000 और इसके बाद के संस्करण में अनुक्रमणित दृश्य नामक एक सुविधा है जो प्रदर्शन को बेहतर कर सकती है , कुछ कैविटीज़ के साथ:

  1. प्रत्येक दृश्य को अनुक्रमित दृश्य में नहीं बनाया जा सकता है; वे एक का पालन करना दिशा निर्देशों के विशिष्ट सेट है, जो (अन्य प्रतिबंध के अलावा) का मतलब है आप की तरह आम क्वेरी तत्वों शामिल नहीं कर सकते COUNT, MIN, MAX, या TOP
  2. अनुक्रमित विचार डेटाबेस में भौतिक स्थान का उपयोग करते हैं, जैसे एक मेज पर अनुक्रमित।

यह लेख अतिरिक्त लाभों और अनुक्रमित विचारों की सीमाओं का वर्णन करता है :

आप ऐसा कर सकते हैं…

  • दृश्य परिभाषा एक ही डेटाबेस में एक या अधिक तालिकाओं को संदर्भित कर सकती है।
  • एक बार अद्वितीय क्लस्टर्ड इंडेक्स बनाने के बाद, दृश्य के खिलाफ अतिरिक्त गैर-अनुक्रमित इंडेक्स बनाया जा सकता है।
  • आप अंतर्निहित तालिकाओं में डेटा को अपडेट कर सकते हैं - आवेषण, अपडेट, हटाएं और यहां तक ​​कि ट्रंकट्स सहित।

आप नहीं कर सकते ...

  • दृश्य परिभाषा अन्य डेटाबेस में अन्य विचारों, या तालिकाओं का संदर्भ नहीं दे सकती है।
  • इसमें COUNT, MIN, MAX, TOP, बाहरी जोड़ या कुछ अन्य कीवर्ड या तत्व शामिल नहीं हो सकते हैं।
  • आप अंतर्निहित तालिकाओं और स्तंभों को संशोधित नहीं कर सकते। दृश्य को SCHEMABINDING विकल्प के साथ बनाया गया है।
  • आप हमेशा यह अनुमान नहीं लगा सकते हैं कि क्वेरी ऑप्टिमाइज़र क्या करेगा। यदि आप एंटरप्राइज़ संस्करण का उपयोग कर रहे हैं, तो यह स्वचालित रूप से अद्वितीय क्लस्टर इंडेक्स को क्वेरी के लिए एक विकल्प के रूप में विचार करेगा - लेकिन यदि यह "बेहतर" इंडेक्स पाता है, तो इसका उपयोग किया जाएगा। आप ऑप्टिमाइज़र को NOEXPAND संकेत के माध्यम से सूचकांक का उपयोग करने के लिए मजबूर कर सकते हैं - लेकिन किसी भी संकेत का उपयोग करते समय सतर्क रहें।

3
पूरी तरह से असहमत ... एक दृश्य से पढ़ना SQL को फिर से लिखने की अनुमति देता है .. और यह आम तौर पर एक दृश्य से पढ़ने के लिए तेज है (दृश्य के एक डंप से)।
आरोन केम्फ

@AaronKempf, मैं उस पर कुछ संदर्भ देखना पसंद करूंगा, यह मेरा अनुभव नहीं है। जब मैं " View
BradC

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

@AaronKempf सुनिश्चित नहीं है कि मूल प्रश्न (जो किसी क्वेरी के बारे में भी है, एक समान परिदृश्य को उस दृश्य में समान क्वेरी में डालकर) के समान ही है। वैसे भी, मैं यह नहीं देख सकता कि किसी टेबल में किसी दृश्य को कैसे मटेरियल किया जाए, जिससे वह कम हो जाए (यह ठीक वैसा ही है, जब तक कि आपके नए टेबल में अच्छा इंडेक्स न हो।
ब्रैडेक

1
ब्रैड; मैंने इस बारे में एक बहुत बुरा ब्लॉग पोस्ट लिखा है कि इस स्थिति में मेरे प्रदर्शन का 99% प्रदर्शन मुझे कैसे बचा रहा है .. मैं अन्य लेखों के एक जोड़े को लिखने की योजना बना रहा हूं, लेकिन मुझे पता है कि मुझे इसमें एक TON अधिक विवरण डालने की आवश्यकता है। क्या आप इस पर एक नज़र डालते हैं और मुझे बताते हैं कि आप मेरे विवरण के बारे में क्या सोचते हैं? मुझे पता है कि यह अधिक समझ में नहीं आएगा (जब तक कि मुझे 2-3 अन्य लेख न मिलें) .. लेकिन मैं विचारों के साथ प्यार में पागल हूं, और मैं लंबे समय से हूं! accessadp.com/2013/01/22/do-views-increase-performance
आरोन

14

SQL सर्वर में, क्वेरी / व्यू पैरामीटर के आधार पर, क्वेरीज़ व्यू और साधारण SQL क्वेरी दोनों के लिए योजना कैश में संग्रहीत की जाती हैं। दोनों के लिए, उन्हें कैश से हटा दिया जाता है जब वे लंबे समय तक अप्रयुक्त रहे हैं और कुछ अन्य नए सबमिट किए गए क्वेरी के लिए स्थान की आवश्यकता है। जिसके बाद, यदि समान क्वेरी जारी की जाती है, तो इसे पुन: कनेक्ट किया जाता है और योजना को वापस कैश में डाल दिया जाता है। तो नहीं, कोई अंतर नहीं है, यह देखते हुए कि आप एक ही SQL क्वेरी और समान आवृत्ति के साथ एक ही दृश्य का पुन: उपयोग कर रहे हैं।

जाहिर है, सामान्य तौर पर, एक दृश्य, यह बहुत ही स्वभाव से होता है (किसी को लगा कि इसे अक्सर इसे एक दृश्य में बनाने के लिए पर्याप्त उपयोग किया जाना चाहिए) आम तौर पर किसी भी मनमाने ढंग से SQL कथन की तुलना में "पुन: उपयोग" होने की अधिक संभावना है।


14

संपादित करें: मैं गलत था, और आपको ऊपर दिए गए मार्क्स का उत्तर देखना चाहिए

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

मैं एक और अधिक जटिल उदाहरण के साथ सामने आऊंगा और इसे देखने के लिए खुद को समय दूंगा।


1
विचारों का एक और कारण भूमिका आधारित मॉडलों में अभिगम नियंत्रण में सहायता करना है
annakata

1
आप प्रदर्शन में सुधार के बारे में गलत हैं। मैंने अपनी मूल टिप्पणी में कुछ लोगों को समझाने के लिए पर्याप्त व्याख्या नहीं की, लेकिन एमएस के पास प्रदर्शन को बेहतर बनाने के लिए विचारों का उपयोग करने के बारे में स्पष्ट दस्तावेज हैं। नीचे मेरी (अब भारी डाउनवोटेड) प्रतिक्रिया देखें।
मार्क ब्रिटिंगम

7

यदि आप एक भौतिक दृश्य ( स्कीमा बाइंडिंग के साथ ) बनाते हैं तो यह तेज़ हो सकता है । गैर-भौतिकवादी विचार नियमित क्वेरी की तरह ही निष्पादित होते हैं।


स्कीमाबाइंडिंग का प्रदर्शन से बहुत कम लेना-देना है, यह दृश्य के स्कीमा को अंतर्निहित तालिका से बांधता है, इसलिए यह सिंक में रहता है और अनुक्रमित दृश्यों के लिए पूर्व-रीक है।
सैम केसर

5

मेरी समझ यह है कि थोड़ी देर पहले, एक दृश्य तेजी से होगा क्योंकि SQL सर्वर एक निष्पादन योजना को स्टोर कर सकता है और फिर मक्खी पर एक का पता लगाने की कोशिश करने के बजाय इसका उपयोग कर सकता है। मुझे लगता है कि आजकल प्रदर्शन लाभ शायद उतना महान नहीं है जितना एक बार था, लेकिन मुझे यह अनुमान लगाना होगा कि दृश्य का उपयोग करने के लिए कुछ मामूली सुधार होगा।


यह मेरी समझ थी: कोई बात नहीं, कोई और नहीं करता है
annakata

एक प्रदर्शन के दृष्टिकोण से नहीं है - पहुँच प्रतिबंध के साधन के रूप में करता है। लेकिन यह एक और विषय होगा। ;)
अनोनज्र

ओह यकीन है, विचारों का उपयोग करने के लिए बहुत सारे अच्छे कारण हैं, कच्चे प्रश्नों का उपयोग करने के लिए एक भी नहीं: पी
अन्नकटा

4

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


धन्यवाद जॉर्डन ... यह सुनकर खुशी हुई कि यह सारी थ्योरी असली दुनिया में काम करती है ।
मार्क ब्रिटिंघम

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

2

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


यदि दृश्य फ़ील्ड्स का एक छोटा सा सेट है और उन फ़ील्ड्स को तब एक इंडेक्स के साथ कवर किया जाता है, तो SQL सर्वर चतुर होता है जो क्वेरी के दूसरे रूप को पूरा करते समय उस कवरिंग इंडेक्स का उपयोग करने के लिए पर्याप्त होता है?
एंथनीवजोन

1

सब कुछ परिस्थिति पर निर्भर करता है। MS SQL अनुक्रमणित दृश्य सामान्य दृश्य या क्वेरी से अधिक तेज़ होते हैं, लेकिन अनुक्रमित दृश्य का उपयोग किसी मिरर किए गए डेटाबेस इनरविमेंट (MS SQL) में नहीं किया जा सकता है।

किसी भी प्रकार के लूप में एक दृश्य गंभीर मंदी का कारण होगा क्योंकि दृश्य को लूप में कहा जाता है हर बार फिर से दोहराया जाता है। एक क्वेरी के रूप में भी। इस स्थिति में आपके डेटा को लूप में रखने के लिए # या @ का उपयोग करने वाली एक अस्थायी तालिका दृश्य या क्वेरी से अधिक तेज़ होती है।

तो यह सब स्थिति पर निर्भर करता है।


0

कोई व्यावहारिक भिन्न नहीं है और यदि आप BOL पढ़ते हैं तो आप पाएंगे कि कभी भी आपका पुराना पुराना SQL SELECT * FROM X प्लान कोचिंग आदि का लाभ उठाता है।


0

निष्पादन योजना को संग्रहीत करने में कुछ तुच्छ लाभ होना चाहिए, लेकिन यह नगण्य होगा।


0

एक दृश्य का उद्देश्य बार-बार क्वेरी का उपयोग करना है। उस अंत तक, SQL सर्वर, ओरेकल, आदि आमतौर पर आपके दृश्य का "कैशेड" या "संकलित" संस्करण प्रदान करेगा, इस प्रकार इसके प्रदर्शन में सुधार होगा। सामान्य तौर पर, यह "सरल" क्वेरी से बेहतर प्रदर्शन करना चाहिए, हालांकि यदि क्वेरी वास्तव में बहुत सरल है, तो लाभ नगण्य हो सकते हैं।

अब, यदि आप एक जटिल क्वेरी कर रहे हैं, तो दृश्य बनाएं।


0

मेरी खोज में, दृश्य का उपयोग करना सामान्य क्वेरी की तुलना में थोड़ा तेज़ है। मेरी संग्रहीत प्रक्रिया में लगभग 25 मिनट लग रहे थे (एक अलग बड़े रिकॉर्ड सेट और कई जॉइन के साथ काम करना) और दृश्य (गैर-क्लस्टर) का उपयोग करने के बाद, प्रदर्शन थोड़ा तेज था, लेकिन बिल्कुल भी महत्वपूर्ण नहीं था। मुझे इसे नाटकीय परिवर्तन करने के लिए कुछ अन्य क्वेरी ऑप्टिमाइज़ेशन तकनीकों / विधि का उपयोग करना पड़ा।


हम क्वेरी कैसे लिख / डिज़ाइन कर रहे हैं यह बहुत महत्वपूर्ण है।
काटा

मैंने सीटीईई का उपयोग करके एक टेबल से लौटने वाले डेटा को सीमित करने और फिर सीटीई के नाटकीय रूप से कई मामलों में प्रदर्शन में सुधार किया है।
मैट

0

किसी दृश्य से या किसी तालिका से चयन करने से बहुत अधिक समझ में नहीं आएगा।

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

तुम भी तेजी से खोज आवश्यकताओं के लिए विचारों पर सूचकांक बना सकते हैं। http://technet.microsoft.com/en-us/library/cc917715.aspx

लेकिन अगर आप sql इंजन से '% ...%' की तरह खोज रहे हैं, तो टेक्स्ट कॉलम पर एक इंडेक्स से लाभ नहीं होगा। यदि आप अपने उपयोगकर्ताओं को '...%' जैसी खोज करने के लिए बाध्य कर सकते हैं तो इससे भी तेज होगा

एस्प मंचों पर जवाब देने के लिए संदर्भित: https://forums.asp.net/t/1697933.aspx?Which+is+faster+when+using+SELECT+query+VIEW+or+Table+


0

सभी अपेक्षाओं के खिलाफ, कुछ परिस्थितियों में विचार धीमा हैं।

मुझे यह हाल ही में पता चला जब मुझे ओरेकल से खींचे गए डेटा की समस्या थी जिसे दूसरे प्रारूप में मालिश करने की आवश्यकता थी। शायद 20k स्रोत पंक्तियों। एक छोटी सी मेज। ऐसा करने के लिए हमने ओरेकल डेटा को अपरिवर्तित रूप में आयात किया, जैसा कि मैं एक तालिका में कर सकता था और फिर डेटा निकालने के लिए विचारों का उपयोग किया। हमारे पास उन विचारों के आधार पर माध्यमिक विचार थे। शायद 3-4 स्तरों के विचार।

अंतिम प्रश्नों में से एक, जो शायद 200 पंक्तियाँ निकालेगा, 45 मिनट से अधिक समय लेगा! यह प्रश्न विचारों के एक झरने पर आधारित था। शायद ३-४ स्तर गहरे।

मैं प्रत्येक विचार को प्रश्न में ले सकता हूं, इसके वर्ग को एक नेस्टेड क्वेरी में सम्मिलित कर सकता हूं और कुछ सेकंड में निष्पादित कर सकता हूं।

हमने यह भी पाया कि हम प्रत्येक दृश्य को एक अस्थायी तालिका में भी लिख सकते हैं और क्वेरी कर सकते हैं कि दृश्य के स्थान पर और यह अभी भी नेस्टेड दृश्यों का उपयोग करने की तुलना में तेज़ था।

क्या और भी अजीब बात थी कि प्रदर्शन तब तक ठीक था जब तक कि हम डेटाबेस में खींची जा रही स्रोत पंक्तियों की कुछ सीमा को हिट नहीं करते, प्रदर्शन कुछ दिनों की जगह पर एक चट्टान को गिरा देता है - कुछ और स्रोत पंक्तियाँ यह सब ले लिया गया था।

इसलिए, ऐसे प्रश्नों का उपयोग करना जो विचारों से खींचते हैं, जो एक नेस्टेड क्वेरी की तुलना में बहुत धीमा है - जो मेरे लिए कोई मतलब नहीं है।


-1

मैं इस धागे के पार चला गया और ब्रेंट ओजर से इस पोस्ट को साझा करना चाहता था जब उपलब्धता समूहों का उपयोग करने पर विचार किया जाए।

ब्रेंट ओजर बग रिपोर्ट

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.