* सेलेक्ट कॉलम चुनें

Question

यदि मुझे केवल 2/3 कॉलम की आवश्यकता है और मैं SELECT *उन क्वेरी को चुनिंदा क्वेरी में प्रदान करने के बजाय क्वेरी करता हूं , तो क्या अधिक / कम I / O या मेमोरी के बारे में कोई प्रदर्शन गिरावट है?

नेटवर्क ओवरहेड मौजूद हो सकता है अगर मैं बिना किसी आवश्यकता के * का चयन करता हूं।

लेकिन एक चुनिंदा ऑपरेशन में, क्या डेटाबेस इंजन हमेशा डिस्क से परमाणु टपल खींचता है, या क्या यह केवल उन कॉलमों को खींचता है जो चयनित ऑपरेशन में अनुरोध किए गए हैं?

यदि यह हमेशा एक नल खींचता है तो I / O ओवरहेड समान है।

उसी समय, टुपल से अनुरोधित कॉलम को अलग करने के लिए मेमोरी खपत हो सकती है, अगर यह एक टपल को खींचती है।

इसलिए यदि ऐसा है, तो कुछ का चयन करें पूर्व-चयन की तुलना में अधिक मेमोरी ओवरहेड होगा

Comments

क्या कोई विशिष्ट RDBMS है जिसके बारे में आप पूछ रहे हैं? यह संभव है कि SELECTप्रश्नों को कैसे निष्पादित / संसाधित किया जाता है, डेटाबेस से डेटाबेस में भिन्न होता है।

— लेसे माजे

एक तरफ के रूप में, PostgreSQL में, यदि आप कहते हैं CREATE VIEW foo_view AS SELECT * FROM foo;, तो बाद में तालिका foo में कॉलम जोड़ें, वे कॉलम स्वचालित रूप से foo_view में अपेक्षित रूप से दिखाई नहीं देंगे। दूसरे शब्दों में, *इस संदर्भ में केवल एक बार (दृश्य निर्माण समय पर) का विस्तार होता है, न कि चयन के अनुसार। ALTER TABLE से उत्पन्न होने वाली जटिलताओं के कारण, मैं कहूँगा कि (व्यवहार में) *इसे हानिकारक माना जाता है।

— जॉय एडम्स

@JoeyAdams - सिर्फ PostgresQL नहीं, यह भी Oracle का व्यवहार है।

— एपीसी

@OMG पॉनीज़: मुझे ऐसी ही पोस्ट की जानकारी नहीं थी। हालाँकि ये वास्तव में सिमेनर नहीं हैं। @ Lèse majesté: मैं जेनेरिक RDBMS के बारे में बात कर रहा हूँ। किसी भी विशिष्ट विक्रेता @Joey एडम्स के बारे में नहीं: हम्म मुझे पता है कि * असुरक्षित है। बस के बारे में प्रदर्शन के मुद्दों पर चर्चा करना चाहते हैं।

— नील बसु

डुप्लिकेट का संभावित डुप्लिकेट * हानिकारक क्यों माना जाता है?

— हारून बर्ट्रेंड

Answer 1

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

यह हमेशा एक टपल खींचता है, क्योंकि (प्रत्येक विक्रेता RDBMS में मैं परिचित हूं), सब कुछ के लिए अंतर्निहित डिस्क भंडारण संरचना (तालिका डेटा सहित) परिभाषित I / O पृष्ठ (उदाहरण के लिए SQL सर्वर में, प्रत्येक पृष्ठ ) पर आधारित है 8 किलोबाइट)। और हर I / O रीड या राइट पेज के द्वारा होता है .. यानी, हर राइट या रीड पूरा डेटा का पेज होता है।

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

अपवाद। एकमात्र स्थान जहां Select *ठीक है, उप-क्वेरी में Existsया के Not Existsरूप में एक विधेय खंड के बाद है:

   Select colA, colB
   From table1 t1
   Where Exists (Select * From Table2
                 Where column = t1.colA)

संपादित करें: @ माइक शेरेर टिप्पणी को संबोधित करने के लिए, हाँ यह सच है, दोनों तकनीकी रूप से, आपके विशेष मामले के लिए थोड़ी परिभाषा के साथ, और सौंदर्यशास्त्र से। सबसे पहले, तब भी जब अनुरोध किए गए स्तंभों का समूह किसी अनुक्रमणिका में संग्रहीत लोगों का सबसेट होता है, क्वेरी प्रोसेसर को उस सूचकांक में संग्रहीत प्रत्येक कॉलम को प्राप्त करना चाहिए , न कि केवल उन्हीं कारणों से अनुरोध किया गया है - सभी I / O में किया जाना चाहिए पेज, और इंडेक्स डेटा को टेबल डेटा की तरह ही IO Pages में स्टोर किया जाता है। इसलिए यदि आप एक इंडेक्स पेज के लिए "टपल" को परिभाषित करते हैं, तो इंडेक्स में संग्रहीत कॉलम के सेट के रूप में, कथन अभी भी सत्य है।
और कथन सौन्दर्य रूप से सत्य है क्योंकि बिंदु यह है कि यह I / O पृष्ठ में संग्रहीत डेटा के आधार पर प्राप्त करता है, न कि आप जो मांगते हैं उस पर आधारित है, और यह सच है कि क्या आप आधार तालिका I / O पृष्ठ या एक अनुक्रमणिका का उपयोग कर रहे हैं मैं / ओ पेज।

उपयोग न करने के अन्य कारणों के लिए Select *, देखें कि हानिकारक क्यों SELECT *माना जाता है? :

Comments

"यह हमेशा एक टपल खींचता है" क्या आपको यकीन है? हम्म ठीक है तो मैं सही था। अगर यह मामला select *कम स्मृति ओवरहेड की तुलना में select columnएक ही मैं / ओ ओवरहेड होगा। इसलिए यदि हम नेटवर्क ओवरहेड छोड़ देते हैं। select *अगर उससे कम ओवरहेडselect column

— नील बसु

यह सच नहीं है। मेरे सिर के ऊपर से एक उदाहरण यह है कि जब आप MySQL में केवल एक अनुक्रमित कॉलम का मूल्य चाहते हैं (उदाहरण के लिए, केवल पंक्ति अस्तित्व की जांच करने के लिए), और आप MyISAM संग्रहण इंजन का उपयोग कर रहे हैं, यह डेटा से डेटा लेगा MYI फ़ाइल, जो मेमोरी में हो सकती है, और डिस्क पर भी नहीं जा सकती है!

— माइक शेरोव

हां अगर टपल का अनुरोधित सेट स्मृति में है तो कोई I / O नहीं होगा, लेकिन विशेष मामला है। तो क्या गर्मी है। यदि मैं कुछ अनुक्रमित कॉलम का चयन करता हूं तो संपूर्ण ट्यूपल पढ़ा नहीं जाता है? अन्यथा पूरी तरह से पढ़ा जाता है?

— नील बसु

मुझे बिल्कुल यकीन नहीं है कि MySql कैशिंग कैसे करता है, लेकिन SQL सर्वर में, और Oracle में, यहां तक ​​कि जब डेटा इन-मेमोरी कैश होता है, तब भी यह उसी पृष्ठ संरचना का उपयोग करके इसे एक्सेस करता है क्योंकि यह डिस्क से एक्सेस करते समय होता है। इसका अर्थ है कि इसे डेटा के प्रति पृष्ठ एक मेमोरी I / O की आवश्यकता होगी ... ठीक उसी तरह जैसे कि यह डिस्क से होगा। (मेमोरी I / Os को छोड़कर, डिस्क I / Os की तुलना में बहुत तेज है)। दरअसल, यह कैशिंग डिजाइन का एक लक्ष्य है, जिससे डेटा के स्थान पर पहुंच प्रक्रिया पूरी तरह से स्वतंत्र हो जाती है।

— चार्ल्स ब्रेटाना

क्या आप "कई अन्य कारणों से" अधिक जादू कर सकते हैं? क्योंकि वे मेरे लिए स्पष्ट नहीं थे। यदि प्रदर्शन से कोई फर्क नहीं पड़ता है, तो कॉलम नामों के अनुरोध के बारे में क्यों ध्यान रखें?

— डेनिस

Answer 2

कई कारण हैं जो आपको SELECT *उत्पादन कोड में कभी (कभी नहीं) का उपयोग करना चाहिए :

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

• यदि आपको स्तंभों में से केवल 2/3 की आवश्यकता है, तो आप 1/3 बहुत अधिक डेटा का चयन कर रहे हैं जिसे डिस्क से पुनर्प्राप्त करने और नेटवर्क में भेजने की आवश्यकता है

• यदि आप डेटा के कुछ पहलुओं पर भरोसा करना शुरू करते हैं, उदाहरण के लिए, स्तंभों का क्रम वापस आ गया है, तो तालिका के पुनर्गठन और नए कॉलम जोड़े जाने के बाद (या मौजूदा हटाए गए) आप एक आश्चर्यचकित हो सकते हैं

• SQL सर्वर में (अन्य डेटाबेस के बारे में निश्चित नहीं), यदि आपको स्तंभों के सबसेट की आवश्यकता है, तो हमेशा एक मौका होता है कि एक गैर-क्लस्टर इंडेक्स उस अनुरोध को कवर कर सकता है (जिसमें सभी कॉलम आवश्यक हों)। ए के साथ SELECT *, आप गेट-गो से उस संभावना को छोड़ रहे हैं। इस विशेष मामले में, डेटा को इंडेक्स पेजों से पुनर्प्राप्त किया जाएगा (यदि वे सभी आवश्यक कॉलम हैं) और इस प्रकार डिस्क I / O और मेमोरी ओवरहेड SELECT *....क्वेरी करने की तुलना में बहुत कम होगी ।

हां, यह शुरू में थोड़ा अधिक टाइपिंग लेता है ( SQL सर्वर के लिए SQL प्रॉम्प्ट जैसे उपकरण यहां तक ​​कि आपकी मदद करेंगे) - लेकिन यह वास्तव में एक मामला है जहां बिना किसी अपवाद के एक नियम है: कभी भी अपने उत्पादन कोड में SELECT * का उपयोग न करें। कभी।

Comments

व्यवहार में आपसे सहमत होते हुए, आप निश्चित रूप से सभी मामलों में सही होते हैं, जब तालिका से कॉलम डेटा लाते हैं, जैसा कि यह प्रश्न पता है), yr पर जोर फिर भी मुझे यह इंगित करने के लिए ड्राइव करता है कि यह नियम सभी एसक्यूएल प्रश्नों के लिए सामान्य नहीं है .. विशेष रूप से, इसका उपयोग एक उप-परीक्षा के बाद एक उप-परीक्षा में किया जाता है, (जैसा कि Where Exists (Select * From ...) का उपयोग Select *निश्चित रूप से कोई समस्या नहीं है, और कुछ हलकों में एक सर्वोत्तम अभ्यास माना जाता है।

— चार्ल्स ब्रेटाना

@Charles Bretana: हाँ, IF EXISTS(SELECT *...एक विशेष मामला है - क्योंकि वहाँ से, कोई डेटा वास्तव में पुनर्प्राप्त नहीं किया गया है, लेकिन यह सिर्फ अस्तित्व के लिए जाँच है, चयन * वहाँ एक मुद्दा नहीं है ...

— marc_s

अगर मैं एक एपीआई विकसित कर रहा हूं, तो इसके बारे में मेरी एक तालिका से डेटा पुनर्प्राप्त करना संभव है। चूंकि मुझे नहीं पता होगा कि उपयोगकर्ता किस डेटा में रुचि रखता है, मुझे लगता है कि SELECT * स्वीकार्य होगा?

— साइमन बेंग्सटन

@SimonBengtsson: मैं अभी भी इस के खिलाफ तर्क दूंगा - मान लीजिए कि आपके टेबल में विशिष्ट कॉलम में कुछ "प्रशासनिक" डेटा है जिसे आप ग्राहक को उजागर नहीं करना चाहते हैं? मैं हमेशा स्पष्ट रूप से कॉलम की एक सूची निर्दिष्ट करूंगा

— marc_s

यह सच है। एपीआई के साथ उपयोग किए जाने वाले विशेष रूप से सेटअप करने वाले दृश्य को क्वेरी करते समय क्या होगा?

— साइमन बेंग्सटन

Answer 3

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

[संपादित करें]: मतलब तक पहुँचने। मूर्ख मस्तिष्क अभी भी जाग रहा है।

Comments

एक किनारे के मामले के लिए +1 जो मुझे विश्वास है कि बहुत से लोग पहली नज़र में नहीं सोचेंगे - क्लाइंट साइड पर अनुक्रमणिका और जोड़े / बदले गए कॉलम।

— टॉमस एशचन

हाँ, लेकिन आम है कि कॉलम के लिए संख्यात्मक सूचकांक का उपयोग? ORM का उपयोग करते समय मैंने हमेशा स्ट्रिंग कुंजियों या संपत्ति के नामों का उपयोग करते हुए कॉलम डेटा तक पहुंच प्राप्त की है।

— लेजे मेजेस्टे

यह एक लंबे समय से पहले देखा, जूनियर प्रोग्रामर एक मेज से * चयनित और स्तंभ के आदेश के बारे में धारणा बना; जैसे ही किसी और ने टेबल बदली उसका सारा कोड टूट गया। हमें क्या मज़ा आया।

— पॉल मैकेंजी

आमतौर पर सिर्फ कोड पठनीयता के लिए कॉलम ऑर्डर का उपयोग करना एक बुरा विचार है, SELECT *इसके साथ उपयोग करने के लिए दोगुना बुरा है।

— लेज़ माजे

वाह, क्लाइंट कोड में सूचकांक द्वारा कॉलम तक पहुंचना एक अभूतपूर्व बुरे विचार की तरह लगता है। उस मामले के लिए, उस क्रम पर निर्भर करना जिसमें किसी भी तरह से सेट किए गए परिणाम में कॉलम मेरे लिए बहुत गंदा लगता है।

— मैट पीटरसन

Answer 4

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

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

Answer 5

यह तुरंत मुझे एक ऐसी तालिका के बारे में सोचता है जो मैं उपयोग कर रहा था जिसमें एक प्रकार का कॉलम था blob; इसमें आमतौर पर JPEG इमेज होती है, जो Mbआकार में कुछ ही होती है।

कहने की ज़रूरत नहीं कि मैंने नहीं किया SELECT कि जब तक मुझे वास्तव में इसकी आवश्यकता वह कॉलम । उस डेटा के इर्द-गिर्द तैरते रहना - विशेषकर जब मैंने mulitple पंक्तियों को चुना - बस एक परेशानी थी।

हालाँकि, मैं मानता हूँ कि मैं आमतौर पर एक तालिका में सभी स्तंभों के लिए क्वेरी करता हूँ।

Comments

LOB कॉलम हमेशा सेलेक्ट * के खतरों का मेरा पसंदीदा उदाहरण है। इसलिए जब तक मैं तीसरा पैराग्राफ नहीं पढ़ता, मैं आपको उखाड़ने वाला था। Tsk, tsk। यदि कोई अन्य डेवलपर किसी तालिका में BLOB जोड़ता है, जिसमें वर्तमान में ऐसा कोई स्तंभ नहीं है?

— एपीसी

@APC, काश मैं आपकी टिप्पणी को और बढ़ा पाता। अपने गरीब सहकर्मी के बारे में सोचें जो केवल एक विशाल प्रदर्शन मेलोडाउन पैदा किए बिना एक कॉलम जोड़ना चाहता है! सोचें कि जब वे आपके मासूम दिखने वाले चयन को कुछ घंटों के बाद खोज लेंगे तो उन्हें कितना गुस्सा आएगा।

— माइक शेरोव

@ user256007, हां, BLOB के बिना भी ... BLOB सिर्फ चरम उदाहरण को दिखाता है। चार्ल्स के लिए मेरी प्रतिक्रिया की जाँच करें, ऐसे समय होते हैं जब विशिष्ट कॉलम का चयन करने से आप डिस्क से जाने के बिना भी डेटा को मेमोरी से हड़पने में सक्षम हो सकते हैं!

— माइक शेरोव

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

— माइक शेरोव

@ user256007 - सामान्य नियम यह है कि "SELECT * का उपयोग न करें। marc_s के उत्तर में सभी आश्वस्त हैं कि ऐसा क्यों है।

— APC

Answer 6

एक SQL चयन के दौरान, DB हमेशा तालिका के लिए मेटाडेटा को संदर्भित करने जा रहा है, चाहे वह किसी भी, SEL, a, b, c के लिए सेलेक्ट * हो ... क्यों? बिकूज़ वह जगह है जहाँ सिस्टम पर तालिका की संरचना और लेआउट की जानकारी होती है।

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

अब, जाहिर है, डीबी मेटाडेटा सिस्टम में कैश किया गया है, लेकिन यह अभी भी प्रसंस्करण है जिसे करने की आवश्यकता है।

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

केवल यही प्रक्रिया नहीं की जाती है जब DB एक पूर्व संकलित क्वेरी का उपयोग कर रहा है, या पिछली क्वेरी को कैश कर दिया है। यह शाब्दिक एसक्यूएल के बजाय बाध्यकारी मापदंडों का उपयोग करने का तर्क है। "" जहां से कुंजी = 1 "का चयन करें" से अलग है? और "1" कॉल पर बाध्य है।

DBs वहाँ काम के लिए पेज कैशिंग पर बहुत भरोसा करते हैं। कई आधुनिक DBs पूरी तरह से मेमोरी में फिट होने के लिए पर्याप्त हैं (या, शायद मुझे कहना चाहिए, आधुनिक मेमोरी कई DBs फिट करने के लिए काफी बड़ी है)। फिर पिछले छोर पर आपकी प्राथमिक I / O लागत लॉगिंग और पेज फ्लश है।

हालाँकि, यदि आप अभी भी अपने DB के लिए डिस्क को मार रहे हैं, तो कई प्रणालियों द्वारा किया गया एक प्राथमिक ऑप्टिमाइज़ेशन, तालिकाओं में डेटा पर भरोसा करने के लिए है, न कि तालिकाओं के बजाय।

यदि आपके पास है:

CREATE TABLE customer (
    id INTEGER NOT NULL PRIMARY KEY,
    name VARCHAR(150) NOT NULL,
    city VARCHAR(30),
    state VARCHAR(30),
    zip VARCHAR(10));

CREATE INDEX k1_customer ON customer(id, name);

फिर यदि आप "SELECT id, नाम फ्रॉम कस्टमर व्हेयर आईडी = 1" करते हैं, तो यह बहुत संभव है कि आप डीबी को टेबल्स के बजाय इंडेक्स से इस डेटा को खींचेंगे।

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

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

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

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

Comments

क्या, मैंने आपके उत्तर को अस्वीकार कर दिया है, सिर्फ इसलिए कि आप PRIMARY KEY के साथ NOT NULL का उपयोग करते हैं। क्या आपके पास इस तरह से लिखने का एक अच्छा कारण है?

— लर्नर

Answer 7

मुझे लगता है कि आपके प्रश्न का कोई सटीक उत्तर नहीं है, क्योंकि आपके पास अपने ऐप्स को बनाए रखने के लिए प्रदर्शन और सुविधा है। Select columnका अधिक प्रदर्शन है select *, लेकिन यदि आप एक उन्मुख वस्तु प्रणाली विकसित कर रहे हैं, तो आप उपयोग करना पसंद करेंगे object.propertiesऔर आपको ऐप्स के किसी भी हिस्से में गुणों की आवश्यकता हो सकती है, तो आपको विशेष स्थितियों में गुण प्राप्त करने के लिए और अधिक तरीकों को लिखने की आवश्यकता होगी यदि आप नहीं करते हैं उपयोग करें select *और सभी गुणों को आबाद करें । आपके ऐप्स को उपयोग करने के लिए एक अच्छे प्रदर्शन की आवश्यकता होती है select *और कुछ मामलों में आपको प्रदर्शन में सुधार के लिए चुनिंदा कॉलम का उपयोग करना होगा। तब आपको दो दुनियाओं से बेहतर, लिखने की सुविधा और एप्स और प्रदर्शन को बनाए रखने की सुविधा होगी जब आपको प्रदर्शन की आवश्यकता होगी।

Answer 8

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

आपको हमेशा सेलेक्ट मेंटेन, सेलेक्ट नहीं .... सेलेक्ट करना चाहिए।

यह मुख्य रूप से प्रदर्शन के मुद्दों के लिए है।

उपयोगकर्ताओं से नाम का चयन करें जहां नाम = 'जॉन';

बहुत उपयोगी उदाहरण नहीं है। इसके बजाय विचार करें:

SELECT telephone FROM users WHERE name='John';

यदि (नाम, टेलीफोन) पर एक सूचकांक है, तो तालिका से संबंधित मूल्यों को देखने के बिना क्वेरी को हल किया जा सकता है - एक कवरिंग इंडेक्स है।

इसके अलावा, मान लें कि तालिका में उपयोगकर्ता का एक चित्र और एक अपलोड किया गया CV, और एक स्प्रेडशीट है ... SELECT * का उपयोग करके यह सब जानकारी वापस DBMS बफ़र (कैश से अन्य उपयोगी जानकारी के लिए मजबूर) को रद्द कर देगा। फिर यह सब नेटवर्क पर समय का उपयोग करके क्लाइंट को भेजा जाएगा और डेटा के लिए क्लाइंट पर मेमोरी जो बेमानी है।

यदि क्लाइंट डेटा को एन्यूमरेटेड सरणी (जैसे PHP के mysql_fetch_array ($ x, MYSQL_NUM)) के रूप में प्राप्त करता है, तो यह कार्यात्मक समस्याओं का कारण भी बन सकता है। हो सकता है कि जब कोड लिखा गया था 'टेलीफोन' SELECT * द्वारा लौटाया जाने वाला तीसरा स्तंभ था, लेकिन तब कोई व्यक्ति साथ आता है और 'टेलीफोन' से पहले तैनात तालिका में एक ईमेल पता जोड़ने का फैसला करता है। वांछित क्षेत्र अब 4 वें कॉलम में स्थानांतरित कर दिया गया है।

Answer 9

किसी भी तरह से चीजें करने के कारण हैं। मैं PostgreSQL पर SELECT * का बहुत उपयोग करता हूं क्योंकि PostgreSQL में आप SELECT * के साथ बहुत सी चीजें कर सकते हैं जो आप एक स्पष्ट कॉलम सूची के साथ नहीं कर सकते हैं, खासकर जब संग्रहीत प्रक्रियाओं में। इन्फ़ॉर्मिक्स में इसी तरह, एक विरासत वाले टेबल ट्री पर सेलेक्ट * आपको दांतेदार पंक्तियाँ दे सकता है, जबकि एक स्पष्ट कॉलम सूची नहीं दे सकती है क्योंकि चाइल्ड टेबल में अतिरिक्त कॉलम भी वापस आ जाते हैं।

PostgreSQL में ऐसा करने का मुख्य कारण यह है कि यह सुनिश्चित करता है कि मुझे एक तालिका के लिए एक अच्छी तरह से गठित प्रकार प्राप्त हो। यह मुझे परिणाम लेने और उन्हें PostgreSQL में तालिका प्रकार के रूप में उपयोग करने की अनुमति देता है। यह एक कठोर कॉलम सूची की तुलना में क्वेरी में कई और विकल्पों की अनुमति देता है।

दूसरी ओर, एक कठोर कॉलम सूची आपको एक एप्लिकेशन-स्तरीय जांच देती है कि db स्कीमा कुछ निश्चित तरीकों से नहीं बदला है और यह मददगार हो सकता है। (मैं इस तरह की जाँच दूसरे स्तर पर करता हूँ।)

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

लेकिन ध्यान रखें कि मैं सेलेक्ट * का उपयोग कर रहा हूं, आमतौर पर बेस टेबल के बजाय एब्सट्रैक्शन लेयर के खिलाफ।

Answer 10

इस लेख से लिया गया संदर्भ:

बिना सेलेक्ट *: जब आप उस समय "सेलेक्ट *" का उपयोग कर रहे होते हैं तो आप डेटाबेस से अधिक कॉलम का चयन कर रहे होते हैं और इस कॉलम में से कुछ का उपयोग आपके एप्लिकेशन द्वारा नहीं किया जा सकता है। यह डेटाबेस सिस्टम पर अतिरिक्त लागत और भार पैदा करेगा और पूरे नेटवर्क में अधिक डेटा यात्रा करेगा।

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

Answer 11

केवल उस चर्चा में एक बारीकियों को जोड़ने के लिए जिसे मैं यहाँ नहीं देखता: I / O के संदर्भ में, यदि आप स्तंभ-उन्मुख भंडारण वाले डेटाबेस का उपयोग कर रहे हैं A LOT कम I / O कर सकते हैं यदि आप केवल कुछ के लिए क्वेरी करते हैं। कॉलम। जैसा कि हम SSDs में जाते हैं, फायदे थोड़े छोटे बनाम पंक्ति-उन्मुख भंडारण हो सकते हैं, लेकिन क) केवल उन ब्लॉकों को पढ़ना है जिनमें आपके द्वारा ख के बारे में परवाह किए जाने वाले कॉलम हैं), जो आमतौर पर डिस्क पर डेटा के आकार को कम करता है और इसलिए डिस्क से पढ़े गए डेटा की मात्रा।

यदि आप कॉलम-ओरिएंटेड स्टोरेज से परिचित नहीं हैं, तो Postgres के लिए एक कार्यान्वयन साइटस डेटा से आता है, दूसरा ग्रीनप्लम है, एक अन्य पार्सल, दूसरा (शिथिल रूप से बोलना) अमेज़ॅन रेडशिफ्ट है। MySQL के लिए Infobright है, अब nigh-defunct InfiniDB है। अन्य व्यावसायिक पेशकशों में HP, Sybase IQ, Teradata से वर्टिका ...

Answer 12

select * from table1 INTERSECT  select * from table2

बराबरी का

select distinct t1 from table1 where Exists (select t2 from table2 where table1.t1 = t2 )

Comments

क्या आप अपने कोड को हाइलाइट करके और Ctrl + K

— WhatsThePoint