मुझे पता है कि आप MySQL में FIRST और AFTER के साथ कॉलम ऑर्डर को बदल सकते हैं, लेकिन आप परेशान क्यों करना चाहेंगे? चूंकि डेटा डालते समय अच्छे प्रश्न स्पष्ट रूप से स्तंभों का नाम देते हैं, क्या वास्तव में आपके कॉलम में तालिका में किस क्रम में देखभाल करने का कोई कारण है?
क्या किसी तालिका में स्तंभ क्रम के बारे में चिंता करने का कोई कारण है?
जवाबों:
Sql Server, Oracle, और MySQL में फैले कुछ डेटाबेस पर कॉलम ऑर्डर का बड़ा प्रदर्शन प्रभाव था। इस पोस्ट में अंगूठे के अच्छे नियम हैं :
- प्राथमिक कुंजी कॉलम पहले
- विदेशी कुंजी कॉलम आगे।
- अक्सर अगले स्तंभों की खोज की
- बाद में अक्सर अपडेट किए गए कॉलम
- अशक्त स्तंभ अंतिम।
- अधिक बार उपयोग किए जाने योग्य स्तंभों के बाद कम से कम उपयोग किए जाने योग्य स्तंभों का उपयोग करें
प्रदर्शन में अंतर के लिए एक उदाहरण एक सूचकांक खोज है। डेटाबेस इंजन सूचकांक में कुछ शर्तों के आधार पर एक पंक्ति पाता है, और एक पंक्ति पता वापस पाता है। अब कहते हैं कि आप SomeValue की तलाश कर रहे हैं, और यह इस तालिका में है:
SomeId int,
SomeString varchar(100),
SomeValue int
इंजन को यह अनुमान लगाना होगा कि कहां से शुरू होता है, क्योंकि कुछ स्ट्रिंग की अज्ञात लंबाई है। हालाँकि, यदि आप इस क्रम को बदलते हैं:
SomeId int,
SomeValue int,
SomeString varchar(100)
अब इंजन को पता है कि SomeValue को पंक्ति की शुरुआत के बाद 4 बाइट्स मिल सकते हैं। तो स्तंभ क्रम में काफी प्रदर्शन प्रभाव पड़ सकता है।
EDIT: Sql Server 2005 पंक्ति की शुरुआत में निश्चित लंबाई वाले क्षेत्रों को संग्रहीत करता है। और प्रत्येक पंक्ति में एक varchar की शुरुआत का संदर्भ है। यह मेरे द्वारा ऊपर सूचीबद्ध प्रभाव को पूरी तरह से नकार देता है। इसलिए हाल के डेटाबेस के लिए, कॉलम ऑर्डर का अब कोई प्रभाव नहीं है।
4
@TopBanana: varchars के साथ नहीं, यही कारण है कि उन्हें सामान्य चार कॉलम में अलग करता है।
—
एलन लालोंडे
मुझे नहीं लगता कि TABLE में कॉलम का क्रम कोई अंतर करता है - यह निश्चित रूप से उन INDEXES में अंतर करता है जो आप बना सकते हैं, सच है।
—
marc_s
@TopBanana: यकीन नहीं है कि आप ओरेकल को जानते हैं या नहीं, लेकिन यह एक VARCHAR2 (100) के लिए 100 बाइट्स आरक्षित नहीं करता है
—
क्वासोई
@Quassnoi: सबसे अधिक प्रभाव Sql सर्वर पर था, एक टेबल पर कई अशक्त varchar () कॉलम थे।
—
एंडोमर
इस उत्तर में URL अब काम नहीं करता है, क्या किसी के पास वैकल्पिक है?
—
स्कन्लिफ
अपडेट करें:
में MySQL, ऐसा करने का एक कारण हो सकता है।
चूंकि चर डेटाटिप्स (जैसे VARCHAR) को चर लंबाई के साथ संग्रहित किया जाता है InnoDB, डेटाबेस इंजन को दिए गए ऑफसेट के बारे में पता लगाने के लिए प्रत्येक पंक्ति में सभी पिछले कॉलमों को पीछे करना चाहिए।
स्तंभों के लिए प्रभाव 17% तक बड़ा हो सकता है 20।
अधिक विस्तार के लिए मेरे ब्लॉग में यह प्रविष्टि देखें:
में Oracle, पीछे वाले NULLकॉलम कोई जगह उपभोग करते हैं, है यही कारण है कि आप उन्हें हमेशा तालिका के अंत करने के लिए रखा जाना चाहिए।
बड़ी पंक्ति के मामले Oracleमें भी ( और SQL Server, में) ROW CHAININGहो सकता है।
ROW CHANING एक पंक्ति को विभाजित करना है जो एक ब्लॉक में फिट नहीं है और इसे एक से अधिक ब्लॉकों में फैली हुई है, एक लिंक की गई सूची के साथ जुड़ा हुआ है।
पहले ब्लॉक में फिट नहीं होने वाले अनुगामी कॉलम को लिंक की गई सूची को ट्रेस करने की आवश्यकता होगी, जिसके परिणामस्वरूप एक अतिरिक्त I/Oऑपरेशन होगा।
देखें इस पेज की व्याख्या के लिए ROW CHAININGमें Oracle:
इसलिए आपको उन स्तंभों को रखना चाहिए जिनका उपयोग आप अक्सर तालिका की शुरुआत में करते हैं, और जिन स्तंभों का आप अक्सर उपयोग नहीं करते हैं, या स्तंभ जो NULLतालिका के अंत तक होते हैं।
महत्वपूर्ण लेख:
यदि आप इस उत्तर को पसंद करते हैं और इसके लिए मतदान करना चाहते हैं, तो कृपया @Andomarउत्तर के लिए भी मतदान करें ।
उसने एक ही बात का जवाब दिया, लेकिन बिना किसी कारण के उसे नीचा दिखाया गया।
तो आप यह कह रहे हैं कि यह धीमा होगा: चयन करें smallTable.id, tblBIG.firstColumn, tblBig.last ) और शामिल हो जाएगा तुल्यकालिक ... लेकिन यह तेजी से होगा: छोटे का चयन करें। लिंक की गई सूची को पार करने की आवश्यकता है क्या मुझे यह अधिकार मिला है?
—
२१:०१
मुझे केवल 6% मिलता है, और यह किसी अन्य कॉलम के लिए col1 बनाम है ।
—
रिक जेम्स
पिछली नौकरी में ओरेकल प्रशिक्षण के दौरान, हमारे डीबीए ने सुझाव दिया कि अशक्त लोगों के सामने सभी गैर-अशक्त कॉलम डालना फायदेमंद था ... हालांकि टीबीएच मुझे इस बात का विवरण याद नहीं है कि क्यों। या हो सकता है कि यह सिर्फ अपडेट होने की संभावना थी अंत में जाना चाहिए? (यदि यह फैलता है तो पंक्ति को स्थानांतरित करने के लिए बंद रखता है)
सामान्य तौर पर, इससे कोई फर्क नहीं पड़ना चाहिए। जैसा कि आप कहते हैं, प्रश्नों को हमेशा "चयन *" से आदेश पर निर्भर रहने के बजाय स्वयं को कॉलम निर्दिष्ट करना चाहिए। मैं किसी भी डीबी के बारे में नहीं जानता जो उन्हें बदलने की अनुमति देता है ... ठीक है, मुझे नहीं पता था कि MySQL ने इसे तब तक अनुमति दी जब तक कि आपने इसका उल्लेख नहीं किया।
वह सही था, ओरेकल कुछ बाइट्स को सहेजने के लिए NULL कॉलम को पीछे नहीं करता है। Dba-oracle.com/oracle_tips_ault_nulls_values.htm
—
एंडोमर
बिल्कुल, यह डिस्क पर आकार में एक बड़ा अंतर
—
एलेक्स
क्या वह लिंक आपका मतलब है? यह स्तंभ क्रम के बजाय सूचकांकों में अशक्त के गैर-अनुक्रमण से संबंधित है।
—
आराकनिद
गलत लिंक, और मूल नहीं मिल सकता है। हालाँकि आप इसके लिए गूगल कर सकते हैं, उदाहरण के लिए ticing.com/new/articles/Chapter2.html
—
एंडोमर 21:09
कुछ बुरी तरह से लिखे गए एप्लिकेशन कॉलम के नाम के बजाय कॉलम ऑर्डर / इंडेक्स पर निर्भर हो सकते हैं। वे नहीं होना चाहिए, लेकिन ऐसा होता है। स्तंभों का क्रम बदलने से ऐसे अनुप्रयोग टूट जाएंगे।
एप्लिकेशन डेवलपर जो अपने कोड को एक टेबल में कॉलम ऑर्डर पर निर्भर करते हैं, अपने एप्लिकेशन को तोड़ने के लिए DESERVE करते हैं। लेकिन एप्लिकेशन के उपयोगकर्ता आउटेज के लायक नहीं हैं।
—
spencer7593
नहीं, SQL डेटाबेस तालिका में स्तंभों का क्रम पूरी तरह से अप्रासंगिक है - प्रदर्शन / मुद्रण उद्देश्यों को छोड़कर। स्तंभों को पुन: व्यवस्थित करने का कोई मतलब नहीं है - अधिकांश सिस्टम ऐसा करने का एक तरीका भी नहीं प्रदान करते हैं (पुरानी तालिका को छोड़कर और इसे नए स्तंभ क्रम से पुन: बनाने के लिए)।
न घुलनेवाली तलछट
EDIT: संबंधपरक डेटाबेस पर विकिपीडिया प्रविष्टि से, यहां प्रासंगिक भाग जो मुझे स्पष्ट रूप से दिखाता है कि कॉलम क्रम कभी नहीं होना चाहिए भी चिंता का विषय होना :
एक संबंध n-tuples के एक सेट के रूप में परिभाषित किया गया है। गणित और संबंधपरक डेटाबेस मॉडल में, एक सेट वस्तुओं का एक अनियोजित संग्रह है, हालांकि कुछ DBMS अपने डेटा के लिए एक आदेश देते हैं। गणित में, एक ट्यूपल के पास एक आदेश होता है, और दोहराव के लिए अनुमति देता है। EF Codd ने मूल रूप से इस गणितीय परिभाषा का उपयोग करके ट्यूल को परिभाषित किया। बाद में, यह ईएफ कोडड की महान अंतर्दृष्टि में से एक था जो एक आदेश के बजाय विशेषता नामों का उपयोग करके संबंधों के आधार पर एक कंप्यूटर भाषा में इतना अधिक सुविधाजनक (सामान्य रूप से) होगा। इस अंतर्दृष्टि का उपयोग आज भी किया जा रहा है।
मैंने देखा है कि कॉलम अंतर का मेरी अपनी आंखों के साथ बड़ा प्रभाव है, इसलिए मैं विश्वास नहीं कर सकता कि यह सही उत्तर है। भले ही मतदान इसे पहले रखता है। मानव संसाधन विकास मंत्री।
—
एंडोमर
क्या एसक्यूएल वातावरण में होगा?
—
marc_s
मैंने देखा सबसे बड़ा प्रभाव Sql Server 2000 पर था, जहां एक विदेशी कुंजी को आगे बढ़ाते हुए कुछ प्रश्नों को 2 से 3 बार तक फैलाया गया था। उन प्रश्नों में विदेशी कुंजी पर एक शर्त के साथ बड़ी तालिका स्कैन (1M + पंक्तियाँ) थीं।
—
एंडोमर
RDBMS तब तक टेबल ऑर्डर पर निर्भर नहीं होता जब तक कि आपको प्रदर्शन की परवाह नहीं है । कॉलम के आदेश के लिए अलग-अलग कार्यान्वयन में अलग-अलग प्रदर्शन दंड होंगे। यह बहुत बड़ा हो सकता है या यह छोटा हो सकता है, यह कार्यान्वयन पर निर्भर करता है। ट्यूपल्स सैद्धांतिक हैं, आरडीबीएमएस व्यावहारिक हैं।
—
एस्टेबन कुबेर
-1। सभी संबंधपरक डेटाबेस जो मैंने उपयोग किए हैं उनमें कुछ स्तर पर कॉलम ऑर्डरिंग है। यदि आप एक तालिका से * का चयन करते हैं, तो आप यादृच्छिक क्रम में कॉलम वापस प्राप्त नहीं करते हैं। अब ऑन-डिस्क बनाम डिस्प्ले एक अलग बहस है। और डेटाबेस के व्यावहारिक कार्यान्वयन के बारे में एक धारणा का समर्थन करने के लिए गणित के सिद्धांत का हवाला देते हुए सिर्फ बकवास है।
—
डग डब्लू
एकमात्र कारण जिसके बारे में मैं सोच सकता हूं कि वह डिबगिंग और अग्निशमन के लिए है। हमारे पास एक तालिका है जिसका "नाम" कॉलम सूची में 10 वें स्थान पर दिखाई देता है। यह एक दर्द है जब आप एक त्वरित चयन करते हैं * तालिका से जहां आईडी (1,2,3) में और फिर आपको नामों को देखने के लिए स्क्रॉल करना होगा।
इसके बारे में बस इतना ही।
जैसा कि अक्सर होता है, सबसे बड़ा कारक अगला लड़का है जिसे सिस्टम पर काम करना पड़ता है। मेरा प्रयास है कि प्राथमिक कुंजी कॉलम पहले, विदेशी कुंजी कॉलम दूसरे, और फिर सिस्टम के लिए महत्व / महत्व के अवरोही क्रम में बाकी कॉलम।
हम आम तौर पर अंतिम कॉलम "बनाया" (जब पंक्ति डाली जाती है तो टाइमस्टैम्प) के साथ शुरू होते हैं। पुराने तालिकाओं के साथ, निश्चित रूप से, इसके बाद कई कॉलम जोड़े जा सकते हैं ... और हमारे पास सामयिक तालिका है जहां एक कंपाउंड प्राथमिक कुंजी को सरोगेट कुंजी में बदल दिया गया था, इसलिए प्राथमिक कुंजी कई स्तंभों से अधिक है।
—
araqnid
यदि आप UNION का बहुत उपयोग करने जा रहे हैं, तो यदि आपके पास उनके ऑर्डर के बारे में एक कन्वेंशन है, तो यह कॉलम को आसान बनाता है।
अपने डेटाबेस की तरह लगता है सामान्य करने की जरूरत है! :)
—
जेम्स एल
अरे! इसे वापस लें, मैंने अपना डेटाबेस नहीं कहा। :)
—
एलन लालोंडे
UNION का उपयोग करने के लिए लाइसेंस कारण हैं;) postgresql.org/docs/current/static/ddl-partitioning.html और stackoverflow.com/questions/863867/… पर
—
एस्टेबन कुबेर 21'09
क्या आप 2 टेबल में कॉलम के क्रम के साथ अलग-अलग क्रम में हो सकते हैं?
—
मोनिका हेडडेक
हां, आपको तालिकाओं को क्वेरी करते समय कॉलम को स्पष्ट रूप से निर्दिष्ट करना होगा। तालिकाओं के साथ ए [, बी] बी [बी], इसका मतलब है (सेलेक्ट आ, अब ए से) यूनिअन (सिलेक्ट बा, बी बी फॉरेन बी) से इंसिडेंट (से सेलेक्ट * ए) यूनि (सिलेक्ट: फॉरम बी)।
—
एलन लालोंड
जैसा कि कहा गया है, कई संभावित प्रदर्शन मुद्दे हैं। यदि आपने अपनी क्वेरी में उन स्तंभों का संदर्भ नहीं दिया था, तो मैंने एक डेटाबेस पर काम किया, जहां अंत में बहुत बेहतर कॉलम डाले। जाहिरा तौर पर अगर एक रिकॉर्ड कई डिस्क ब्लॉक को फैलाता है, तो डेटाबेस इंजन रीडिंग ब्लॉक को रोक सकता है, क्योंकि इसे सभी कॉलमों की आवश्यकता होती है।
बेशक किसी भी प्रदर्शन के निहितार्थ न केवल उस निर्माता पर निर्भर हैं जो आप उपयोग कर रहे हैं, बल्कि संभावित रूप से संस्करण पर भी। कुछ महीने पहले मैंने देखा कि हमारे पोस्टग्रेज एक "जैसे" तुलना के लिए एक सूचकांक का उपयोग नहीं कर सकते थे। यही है, यदि आपने "एम% 'की तरह सोमाकोलॉजी लिखा है, तो यह स्मार्ट नहीं था कि एम को छोड़ दें और जब इसे पहला एन मिला तो मैं इसे" बीच "का उपयोग करने के लिए प्रश्नों का एक गुच्छा बदलने की योजना बना रहा था। फिर हमें पोस्टग्रेज का एक नया संस्करण मिला और इसने बुद्धिमानी से इस तरह का काम संभाला। खुशी है कि मैं कभी भी प्रश्नों को बदलने के लिए तैयार नहीं हुआ। स्पष्ट रूप से यहां सीधे प्रासंगिक नहीं है, लेकिन मेरा कहना यह है कि दक्षता विचारों के लिए आप जो कुछ भी करते हैं वह अगले संस्करण के साथ अप्रचलित हो सकता है।
कॉलम ऑर्डर लगभग हमेशा मेरे लिए बहुत प्रासंगिक है क्योंकि मैं नियमित रूप से जेनेरिक कोड लिखता हूं जो स्क्रीन बनाने के लिए डेटाबेस स्कीमा को पढ़ता है। जैसे, मेरे "एक रिकॉर्ड संपादित करें" स्क्रीन लगभग हमेशा फ़ील्ड की सूची प्राप्त करने के लिए स्कीमा को पढ़कर और फिर उन्हें क्रम में प्रदर्शित करके बनाया जाता है। यदि मैंने कॉलम का क्रम बदल दिया, तो मेरा कार्यक्रम अभी भी काम करेगा, लेकिन प्रदर्शन उपयोगकर्ता के लिए अजीब हो सकता है। जैसे, आप नाम / पता / शहर / राज्य / जिप देखने की अपेक्षा करते हैं, न कि शहर / पता / जिप / नाम / राज्य। ज़रूर, मैं कॉलम के डिस्प्ले ऑर्डर को कोड या एक कंट्रोल फाइल या कुछ और में डाल सकता था, लेकिन फिर हर बार जब हमने एक कॉलम जोड़ा या हटाया तो हमें कंट्रोल फाइल को अपडेट करने के लिए याद रखना होगा। मैं एक बार बातें कहना पसंद करता हूं। इसके अलावा, जब संपादित स्क्रीन पूरी तरह से स्कीमा से निर्मित होती है, एक नई तालिका जोड़ने का मतलब यह हो सकता है कि इसके लिए एक एडिट स्क्रीन बनाने के लिए कोड की शून्य लाइनें लिखी जाए, जो कि शांत है। (ठीक है, ठीक है, व्यवहार में आमतौर पर मुझे जेनेरिक एडिट प्रोग्राम को कॉल करने के लिए मेनू में एक प्रविष्टि जोड़ना पड़ता है, और मैंने आम तौर पर सामान्य "अपडेट करने के लिए एक रिकॉर्ड का चयन करें" पर छोड़ दिया है क्योंकि इसे व्यावहारिक बनाने के लिए बहुत सारे अपवाद हैं ।)
स्पष्ट प्रदर्शन ट्यूनिंग से परे, मैं बस एक कोने के मामले में भाग गया था, जहां पुनरावर्ती कॉलम एक (पहले कार्यात्मक) sql स्क्रिप्ट को विफल करने का कारण बना।
प्रलेखन से "TIMESTAMP और DATETIME कॉलम में कोई स्वचालित गुण नहीं है जब तक कि वे स्पष्ट रूप से निर्दिष्ट न हों, इस अपवाद के साथ: डिफ़ॉल्ट रूप से, पहले TIMESTAMP स्तंभ में DEFAULT CURRENT_TIMESTAMP और ONDDD CURRENT_TIMESTAMP दोनों हैं यदि स्पष्ट रूप से निर्दिष्ट नहीं किया गया है" ONDDD https: //dev.mysql .com / doc / RefMan / 5.6 / en / टाइमस्टैम्प-initialization.html
तो, एक कमांड ALTER TABLE table_name MODIFY field_name timestamp(6) NOT NULL; काम करेगा अगर वह फ़ील्ड तालिका में पहला टाइमस्टैम्प (या डेटाटाइम) है, लेकिन अन्यथा नहीं।
जाहिर है, आप डिफ़ॉल्ट मान को शामिल करने के लिए उस परिवर्तनशील आदेश को सही कर सकते हैं, लेकिन यह तथ्य कि एक कॉलम को पुन: व्यवस्थित करने के कारण काम करने वाली क्वेरी ने मेरे सिर को चोट पहुंचाई है।
सामान्य तौर पर जब आप प्रबंधन स्टूडियो के माध्यम से कॉलम ऑर्डर बदलते हैं, तो SQL सर्वर में क्या होता है, यह नई संरचना के साथ एक अस्थायी तालिका बनाता है, डेटा को पुरानी तालिका से उस संरचना में ले जाता है, पुरानी तालिका को ड्रॉप करता है और नए का नाम बदलता है। जैसा कि आप कल्पना कर सकते हैं, यदि आपके पास एक बड़ी मेज है, तो प्रदर्शन के लिए यह बहुत खराब विकल्प है। मुझे नहीं पता कि मेरा एसक्यूएल ऐसा ही करता है, लेकिन यह एक कारण है कि हममें से कई लोग स्तंभों को फिर से बनाने से बचते हैं। चूंकि चयन * का उपयोग कभी भी उत्पादन प्रणाली में नहीं किया जाना चाहिए, अंत में कॉलम जोड़ना अच्छी तरह से डिज़ाइन किए गए सिस्टम के लिए उपयुक्त नहीं है। स्तंभों का क्रम इंटहे टेबल जनराल में गड़बड़ नहीं होना चाहिए।
2002 में, बिल थोरस्टिंसन ने हेवलेट पैकर्ड मंचों पर पोस्ट किया, जो स्तंभों को पुन: व्यवस्थित करके MySQL प्रश्नों के अनुकूलन के लिए उनके सुझाव थे। तब से उनकी पोस्ट को शाब्दिक रूप से कॉपी किया गया है और इंटरनेट पर कम से कम सौ बार चिपकाया गया है, अक्सर बिना किसी उद्धरण के। उसे उद्धृत करने के लिए ...
अंगूठे के सामान्य नियम:
- प्राथमिक कुंजी कॉलम पहले।
- विदेशी कुंजी कॉलम आगे।
- अगले कॉलम में अक्सर खोजा जाता है।
- बाद में अक्सर अपडेट किए गए कॉलम।
- अशक्त स्तंभ अंतिम।
- अधिक-अक्सर उपयोग किए जाने वाले अशक्त स्तंभों के बाद कम-से-कम उपयोग किए जा सकने योग्य स्तंभ।
- कुछ अन्य स्तंभों के साथ स्वयं की तालिका में बूँदें।
स्रोत: एचपी फोरम
लेकिन 2002 में उस पोस्ट को वापस कर दिया गया! यह सलाह MySQL संस्करण 3.23 के लिए थी, MySQL 5.1 के छह साल से अधिक पहले जारी की जाएगी। और कोई संदर्भ या उद्धरण नहीं हैं। तो, क्या बिल सही था? और इस स्तर पर भंडारण इंजन वास्तव में कैसे काम करता है?
- हाँ, बिल सही था।
- यह सब जंजीर पंक्तियों और स्मृति ब्लॉकों के मामले में आता है।
ओरेकल रो चेनिंग एंड माइग्रेशन के एक लेख पर , एक ओरेकल-प्रमाणित पेशेवर , मार्टिन ज़हेन को उद्धृत करने के लिए ...
जंजीरनुमा पंक्तियां हमें अलग तरह से प्रभावित करती हैं। यहां, यह उस डेटा पर निर्भर करता है जिसकी हमें आवश्यकता है। यदि हमारे पास दो स्तंभों वाली एक पंक्ति थी जो दो ब्लॉकों में फैली थी, तो क्वेरी:
SELECT column1 FROM tableजहां कॉलम 1 ब्लॉक 1 में है, वहाँ किसी भी कारण नहीं होगा «टेबल लाने की पंक्ति»। यह वास्तव में कॉलम 2 प्राप्त नहीं करना होगा, यह सभी तरह से जंजीर पंक्ति का पालन नहीं करेगा। दूसरी ओर, अगर हम मांगते हैं:
SELECT column2 FROM tableऔर column2 पंक्ति 2 में पंक्तिबद्ध होने के कारण होता है, तो आप वास्तव में एक «टेबल लाँच पंक्ति को जारी रखें» देखेंगे
लेख का बाकी हिस्सा एक अच्छा पढ़ा है! लेकिन मैं यहाँ केवल उस भाग को उद्धृत कर रहा हूँ जो सीधे हमारे प्रश्न के लिए प्रासंगिक है।
18 से अधिक वर्षों के बाद, मैं यह कहना चाहता हूँ: धन्यवाद, बिल!
