मेरा प्रश्न MySQL के संबंध में है, लेकिन मुझे आश्चर्य है कि यह अन्य डेटाबेस को कैसे प्रभावित करता है। मेरे पास कई फ़ील्ड हैं जो varchar(255) हैं लेकिन मेरे सहकर्मी जोर देते हैं कि वे varchar(30) थे - या कोई छोटा आकार - तो प्रश्न तेजी से चलेंगे। मुझे इतना यकीन नहीं है, लेकिन अगर ऐसा है तो मैं इसे स्वीकार करूंगा।क्या क्षेत्र का आकार क्वेरी समय को प्रभावित करता है?
यदि आप केवल पहले 30 वर्णों का उपयोग कर रहे हैं, तो वर्चर (30) और वर्कर (255) के बीच कोई अंतर नहीं होगा (हालांकि वर्चर (1000) के साथ कोई अंतर होगा, एक अतिरिक्त बाइट ले जाएगा)।
बेशक, यदि आप 30 से अधिक वर्णों का उपयोग करते हैं, तो यह धीमा हो जाएगा क्योंकि आपके पास क्लाइंट को पास करने के लिए अधिक डेटा है, और आपकी अनुक्रमणिका बड़ी होगी।
यह क्वेरी और डेटा पर निर्भर करता है, लेकिन आप शायद चिंतित होने के लिए जल्द ही अनुकूलित कर रहे हैं।
चयन प्रश्नों के लिए, कथन स्वयं ही MySQL के भीतर जितना तेज़ होगा, और जब तक डेटा छोटे आकार के क्षेत्र में बड़ा नहीं होगा तब तक यह तेज़ी से संचारित होगा। यदि छोटा क्षेत्र आपको जानकारी को एक छोटी जगह में संग्रहीत करने के लिए मजबूर करता है (क्या आप अतिरिक्त 225 वर्णों का उपयोग करेंगे?), तो आपको अन्य कार्यक्रमों में तेजी से संचरण मिलेगा।
INSERT क्वेरी के लिए फ़ील्ड का आकार कोई मुद्दा नहीं है, लेकिन परिवर्तनीय लंबाई फ़ील्ड का उपयोग प्रक्रिया को धीमा कर देगा। निश्चित लंबाई पंक्तियों के साथ INSERT निश्चित रूप से तेज़ हैं (कम से कम MySQL 5.0 और इससे पहले)।
आम तौर पर, डेटा के लिए आवश्यक आकार का उपयोग करें। यदि आपको नहीं पता कि आपको 255 वर्ण या 30 वर्णों की आवश्यकता है तो आप शायद जल्द ही अनुकूलित कर रहे हैं। क्या बड़े डेटा फ़ील्ड बाधा उत्पन्न कर रहे हैं? क्या आप डेटाबेस प्रदर्शन समस्याओं से पीड़ित कार्यक्रम हैं? अपनी बाधाओं को पहले ढूंढें, दूसरी समस्या को हल करें। मुझे लगता है कि आप जिस समय देख रहे हैं उसमें अंतर आप जो भी समस्या हल करने की कोशिश कर रहे हैं उससे महत्वहीन है।
वर्चर (255) से छोटा कुछ भी एक बाइट का उपयोग आकार स्टोर करने के लिए करेगा, इसलिए VARCHAR (30) और VARCHAR (255) कोई फर्क नहीं पड़ता।
लेकिन एक बार देखें कि आपका डेटा सुसंगत है, मेरा मतलब है, हमेशा एक ही आकार, एक मामले का उपयोग कर उस मामले में अधिक उपयोगी होगा क्योंकि आप आकार की जानकारी के साथ समय बर्बाद नहीं करेंगे और आपकी खोज को ढूंढना आसान होगा डेटा, यहां इंडेक्स इंडेक्स में नहीं है।
यहां तक कि अगर आपके डेटा संगत नहीं है, लेकिन का एक पहलू में परिवर्तन का कहना है कि एक बाइट, एक CHAR बेहतर होगा, क्योंकि आप आकार में जानकारी के साथ एक बाइट वैसे भी बर्बाद होगा।
हू? आप 255 अक्षरों को 1 बाइट में फिट कर सकते हैं? यही कारण है कि लोग MySQL का उपयोग करते हैं। यह अविश्वसनीय संपीड़न है। –
मुझे लगता है कि आपको यह नहीं मिला है। VARCHAR (255) से छोटा कुछ भी एक बाइट का उपयोग अपने आकार को स्टोर करने के लिए करेगा, न कि VALUE। आकार को स्टोर करने के लिए 2 बाइट्स का उपयोग करने से कहीं अधिक कुछ भी। अगली बार बेहतर पढ़ें। –
ठीक है। मैं देखता हूं, यह SIZE है ....गॉचा –
बहुत ही कम कॉलम चौड़ाई क्वेरी प्रदर्शन को प्रभावित करेगी। निश्चित रूप से यदि आप बड़ी वस्तुओं (बीएलओबी, लोंगब्लॉब्स, टेक्स्ट, LONGTEXTs) का उपयोग कर रहे हैं, तो बहुत सारे डेटा खींचने की संभावना है। यह संभवतः प्रदर्शन को प्रभावित कर सकता है, लेकिन यह जरूरी नहीं होगा। यह वास्तव में केवल भंडारण को प्रभावित करता है। यदि आप डेटा प्रकार से संग्रहण आकार की परवाह करते हैं, तो आप विवरण देखने के लिए http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html का संदर्भ दे सकते हैं।
और दोहराने के लिए: डेटा का संग्रहण आकार जरूरी प्रश्नों की गति को प्रभावित नहीं करता है। कई अन्य डिज़ाइन विचार हैं जो क्वेरी की गति को प्रभावित करेंगे। टेबल और रिश्ते, कुंजी संरचना, अनुक्रमित, क्वेरी और शामिल होने के वास्तुकला, आदि के डिजाइन
कुछ साल पहले बहुत से लोगों को प्रदर्शन के लिए MySQL में tinytext बजाय varchar का उपयोग कर सुझाव दिया है, क्योंकि पंक्ति खोज द्वारा पंक्ति था माना जाता है कि लगातार साथ तेजी पंक्ति डेटा आकार। निश्चित रूप से MySQL की क्वेरी, स्टोरेज और इंडेक्स हैंडलिंग एल्गोरिदम तब से विकसित हुए हैं और इसका अब इतना प्रभाव नहीं हो सकता है।
लेकिन आप शायद जल्द ही अनुकूलन कर रहे हैं और इस स्तर पर प्रदर्शन के बारे में चिंतित नहीं होना चाहिए।
जब से तुम अन्य डेटाबेस के बारे में पूछा ...
यह बिल्कुल क्वेरी समय को प्रभावित करता है।
ओरेकल में जब डेटा सर्वर से क्लाइंट में स्थानांतरित किया जाता है, तो यह एक बफर के माध्यम से किया जाता है। वहां कुछ भी क्रांतिकारी नहीं है। उस बफर में रखी गई पंक्तियों की संख्या अधिकतम पंक्ति आकार पर आधारित होती है। कहें कि आपकी क्वेरी वर्चर्स के 4 कॉलम लौटाती है। यदि कॉलम का आकार 100 है और यह 10 होना चाहिए, तो ओरेकल प्रत्येक fetch में 10x कम पंक्तियों को फिट करेगा, अन्यथा सही आकार की कॉलम परिभाषाओं के साथ। इसके परिणामस्वरूप ब्लॉक अनावश्यक रूप से फिर से पढ़े जा रहे हैं। यह अधिक नेटवर्क यातायात, अधिक दौर यात्राओं को मजबूर करता है।
ओरेकल में आप SET ARRAYSIZE के साथ बफर का आकार बदल सकते हैं। इसे कभी भी आज़माएं, एक आकार के साथ एक प्रश्न करें और फिर अंतरिक्ष के 10% के साथ फिर से करें। आप देखेंगे कि पढ़ते हैं, नेटवर्क ट्रिप ऊपर जाते हैं, और प्रदर्शन नीचे चला जाता है। कॉलम रास्ता बहुत बड़ा बनाना बस इतना बफर तरीका बनाना बहुत छोटा है।
लेकिन सही आकार के कॉलम का असली कारण डेटा अखंडता है। आप बुरी चीजें निकालते हैं। यह प्रदर्शन के रूप में उतना ही महत्वपूर्ण है।
याद रखें:
अधिकांश अन्य उत्तर तथ्य यह है कि VARCHAR एक चर लंबाई ढंग से संग्रहीत किया जाता है पर ध्यान केंद्रित कर रहे हैं, तो यह स्ट्रिंग आप किसी पंक्ति, नहीं क्षेत्र की अधिकतम लंबाई पर दर्ज की बाइट की संख्या संग्रहीत करता है ।
लेकिन प्रश्नों के दौरान, कुछ परिस्थितियां हैं जहां MySQL एक VARCHAR को एक वर्ण में परिवर्तित करता है - और इसलिए आकार अधिकतम लंबाई तक जाता है। ऐसा होता है, उदाहरण के लिए, जब MySQL कुछ जॉइन या ऑर्डर द्वारा ग्रुप या ऑपरेशन के दौरान एक अस्थायी तालिका बनाता है।
सभी मामलों को बताते हुए यह कहां जटिल होगा, क्योंकि यह इस बात पर निर्भर करता है कि अनुकूलक क्वेरी का इलाज कैसे करता है, यह आपके द्वारा परिभाषित अन्य तालिका संरचना और अनुक्रमणिका पर निर्भर करता है, यह क्वेरी के प्रकार पर निर्भर करता है, और यह भी निर्भर करता है MySQL के संस्करण पर क्योंकि प्रत्येक संस्करण के साथ अनुकूलक में सुधार हुआ है।
संक्षिप्त उत्तर हाँ है, यह कर सकता है चाहे आप VARCHAR (255) या VARCHAR (30) का उपयोग करें। इसलिए परंपरा की खातिर 255 की तरह "बड़ी" लंबाई की आवश्यकता के मुताबिक स्तंभ की अधिकतम लंबाई को परिभाषित करें।
मैं इसे आधिकारिक दस्तावेज़ीकरण में ढूंढ रहा हूं और मुझे इससे संबंधित कुछ भी नहीं मिला। क्या आप मुझे इसके बारे में बता सकते हैं या शायद कुछ * आधिकारिक * संदर्भ प्रदान कर सकते हैं? मैं विशेष रूप से सोच रहा हूं कि 'वचर (10000)' के मामले में क्या होता है जैसा कि मैं समझता हूं कि 'CHAR (255) 'सीमा है। धन्यवाद –
@MostyMostacho, मुझे प्रलेखन में किसी भी संदर्भ के बारे में पता नहीं है। मुझे एक वरिष्ठ डेवलपर ने बताया था जिसने MySQL, Drizzle और Percona सर्वर के लिए स्रोत कोड पर कई सालों तक काम किया है। –
कुछ परिस्थितियों में एक अंतर है। मैंने 4.25 से 3.1 सेकेंड तक पूछताछ की गति बढ़ा दी है, सिर्फ 'वर्चर (255)' से 'वचरर (35)' को कम किया जा रहा है। सबसे लंबा डेटा 27 लंबा था, इसलिए मैंने कुछ भी नहीं खो दिया। प्रश्न में 2 शामिल हैं और 'वर्चर' कॉलम पर 'ग्रुप बाय' का उपयोग किया गया है। –