2010-09-08 54 views
11

केस 1: मेरे पास 30 कॉलम वाली एक टेबल है और मैं कहां से 4 कॉलम का उपयोग कर क्वेरी करता हूं।क्या कॉलम की संख्या क्वेरी प्रदर्शन को प्रभावित करती है?

केस 2: मेरे पास 6 कॉलम वाली एक तालिका है और मैं कहां से 4 कॉलम का उपयोग कर क्वेरी करता हूं।

दोनों मामलों में प्रदर्शन में क्या अंतर है?

उदाहरण के लिए मैं मेज

table A 
{ 
    b varchar(10), 
    c varchar(10), 
    d varchar(10), 
    e varchar(10), 
    f varchar(10), 
    g varchar(10), 
    h varchar(10) 

} 

SELECT b,c,d 
FROM A 
WHERE f='foo' 

create table B 
{ 
    b varchar(10), 
    c varchar(10), 
    d varchar(10), 
    e varchar(10), 
    f varchar(10) 

} 

SELECT b,c,d 
FROM B 
WHERE f='foo' 

दोनों एक है और बी तालिका जहां हालत भी एक ही और चुनिंदा इन स्तंभ है, जिसकी संरचना स्तंभ और स्तंभ में इस्तेमाल की संख्या में फर्क सिर्फ इतना मतलब है भी एक ही है। अंतर यह है कि तालिका बी में केवल कुछ अप्रयुक्त कॉलम हैं जिनका उपयोग इन्हें चुनने में नहीं किया जा रहा है और उस स्थिति में स्थिति दोनों स्थितियों के प्रदर्शन में कोई अंतर है?

उत्तर

9

मुख्य एक SELECT में कम कॉलम लौटने के लाभ (कि SQL तालिका/क्लस्टर से पढ़ने से बचने के लिए सक्षम हो सकता है, और बदले में, अगर यह एक सूचकांक से सभी selected डेटा पुनः प्राप्त कर सकते हैं या तो के रूप में अनुक्रमित कॉलम और/या एक कवर सूचकांक के मामले में कॉलम शामिल)। भविष्य में उपयोग किए गए कॉलम, उदाहरण के लिए f आपके उदाहरण में, इंडेक्स के अनुक्रमित कॉलम में होना चाहिए।

सामान्य स्थिति में, वहाँ भी एक SELECT से कम कॉलम लौटने में एक माध्यमिक लाभ है, के रूप में यह किसी भी मैं/हे भूमि के ऊपर कम हो जाएगा, खासकर अगर वहाँ डेटाबेस सर्वर और ऐप्लिकेशन के बीच धीमा नेटवर्क लगता है डेटा - यानी यह वास्तव में केवल उन स्तंभों को वापस करने के लिए अच्छा अभ्यास है, जिन्हें आप वास्तव में चाहते हैं, और SELECT * का उपयोग करने से बचने के लिए।

संपादित: ओपी के अद्यतन पोस्ट के जवाब में:

सभी में कोई अनुक्रमणिका के साथ

, दोनों प्रश्नों तालिका स्कैन करेंगे। यह देखते हुए कि Table B में Table A से कम कॉलम हैं, प्रति पृष्ठ (घनत्व) पंक्तियां B पर अधिक होंगी और इसलिए B कम से कम तेज़ होगा क्योंकि SQL को कम पृष्ठों को लाने की आवश्यकता होगी। के रूप में प्रति नीचे

  • सूचकांक पर A(f) INCLUDE (b,c,d)
  • सूचकांक B(f) INCLUDE (b,c,d)

पर

हालांकि, सूचकांक के साथ प्रदर्शन, प्रश्नों (दोनों तालिकाओं में एक ही डेटा कल्पना करते हुए) के लिए समान होना चाहिए दिया कि एसक्यूएल इंडेक्स को हिट करेगा जो अब समान स्तंभ चौड़ाई और पंक्ति घनत्व के हैं।

संपादित

कुछ अन्य योजनाओं: कोई अन्य प्रमुख या INCLUDE कॉलम के साथ B(f) पर

  • सूचकांक, या INCLUDE कॉलम का एक अधूरा सेट के साथ (अर्थातएक या b, c or d के और अधिक याद कर रहे हैं):

एसक्यूएल सर्वर की संभावना के रूप में भले ही सूचकांक प्रयोग किया जाता है एक Key or RIDLookup करने की आवश्यकता होगी, लापता पुनः प्राप्त करने के मेज पर वापस "में शामिल होने" करने की जरूरत होगी चयन खंड में कॉलम। (देखने के लिए कि क्या प्रकार तालिका एक संकुल पी है या नहीं पर निर्भर करता है)

  • सीधे गैर क्लस्टर B(f,b,c,d)

इस पर सूचकांक अभी भी बहुत performant हो जाएगा के रूप में सूचकांक का उपयोग किया जाएगा और टेबल से बचा, लेकिन won't be quite as good as the covering index, क्योंकि इंडेक्स में अतिरिक्त कुंजी कॉलम के कारण इंडेक्स पेड़ की घनत्व कम होगी।

+1

+ सूचकांक के उपयोग के लिए –

2

कॉलम स्थिति के आधार पर कोई प्रदर्शन अंतर नहीं होगा। अब तालिका का निर्माण एक अलग कहानी है उदा। पंक्तियों, इंडेक्स, कॉलम की संख्या इत्यादि।

परिदृश्य जहां आप दो तालिकाओं में कॉलम की स्थिति की तुलना कर रहे हैं, इस बारे में बात कर रहे हैं कि सेब की तुलना संतरे से लगभग है, क्योंकि इसके अलावा कई अलग-अलग चर हैं कॉलम स्थिति।

1

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

+0

+ सूचकांक उपयोग के लिए –

2

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

  • आपको क्या चाहिए
  • ही पंक्तियों के लिए एक ही मेज पर दूसरे डेटाबेस क्वेरी से बचने
  • चयन स्तंभ (रों) (कहां खंड restricter) पर एक सूचकांक का उपयोग
  • स्तंभों को प्रतिबंधित करता है, तो तुम नहीं हो जाओ उन्हें डेटा सर्वर मेमोरी दक्षता/पेजिंग
+0

यह कहा जा रहा है कि, SQL सर्वर कई बार मेमोरी में एक संपूर्ण तालिका/अनुक्रमणिका को पकड़ लेगा और फिर काम करेगा जो स्तंभ संख्याओं को म्यूट कर देगा - संदर्भ खोजने का प्रयास कर रहा है। परीक्षण के लिए –

4

परीक्षण और देखने के लिए उनकी आवश्यकता है!

एक प्रदर्शन अंतर होगा, हालांकि 99% बार आप इसे नोटिस नहीं करेंगे - आमतौर पर आप इसे पहचानने में भी सक्षम नहीं होंगे!

आप यह भी गारंटी नहीं दे सकते कि कम कॉलम वाली तालिका तेज हो जाएगी - अगर यह आपको परेशान करता है तो इसे आजमाएं और देखें।

तकनीकी बकवास:

धारणा के साथ

(Microsoft SQL सर्वर के नजरिए से) कि अन्य सभी मामलों (अनुक्रमित, पंक्ति में गिना जाता है, डेटा 6 आम कॉलम आदि में निहित ...) में टेबल समान हैं, तो केवल वास्तविक अंतर यह होगा कि बड़ी तालिका डिस्क/स्मृति में अधिक पृष्ठों पर फैली हुई है।

SQL सर्वर केवल उस डेटा को पढ़ने का प्रयास करता है जिसकी पूरी आवश्यकता है, हालांकि यह हमेशा एक समय में एक संपूर्ण पृष्ठ लोड करेगा (8 KB)। यहां तक ​​कि सटीक राशि के साथ डेटा को क्वेरी के आउटपुट के रूप में आवश्यक है, यदि वह डेटा अधिक पृष्ठों पर फैला हुआ है तो अधिक आईओ आवश्यक है।

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

इसके अलावा, यह भी संभावना है कि आपकी क्वेरी तालिका के बजाए इंडेक्स के खिलाफ चलाएगी, और इसलिए इंडेक्स के साथ बिल्कुल उसी आकार में परिवर्तन होने की संभावना है।

+2

+1 और देखें ;-) –

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

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