मैंने टिप्पणी देखी "यदि आपके पास वर्चर (20) कॉलम में 10 से 15 वर्णों के बीच 50 मिलियन मान हैं, और वर्चर (50) कॉलम में 50 मिलियन मान हैं, तो वे बिल्कुल वही स्थान ले लेंगे। यही वह जगह है चर के विपरीत, वर्चर का पूरा बिंदु। " क्या कोई मुझे कारण बता सकता है? What is a reasonable length limit on person "Name" fields?वर्कर (20) और वर्कर (50) समान हैं?
MySQL भंडारण इंजन का विकल्प प्रदान करता है। डेटा का भौतिक भंडारण भंडारण इंजन पर निर्भर करता है। VARCHAR
MyISAM में की
MyISAM भंडारण, VARCHAR रों आम तौर पर स्ट्रिंग के साथ साथ एक बाइट या लंबाई के दो में से केवल वास्तविक लंबाई पर कब्जा। इसे लॉकिंग क्षमता के विपरीत टेबल लॉकिंग में माईसाम की डिज़ाइन सीमा द्वारा व्यावहारिक बनाया गया है। प्रदर्शन परिणामों में एक अधिक कॉम्पैक्ट कैश प्रोफ़ाइल शामिल है, लेकिन रिकॉर्ड ऑफसेट की अधिक जटिल (धीमी) गणना भी शामिल है।
(वास्तव में, MyISAM आप a degree of choice तय शारीरिक पंक्ति आकार और चर शारीरिक पंक्ति आकार मेज प्रारूपों के बीच स्तंभ प्रकार पूरे तालिका में उत्पन्न के आधार पर देता है। VARCHAR की घटना केवल डिफ़ॉल्ट विधि है, लेकिन एक TEXT ब्लॉब की उपस्थिति में परिवर्तन बलों एक ही तालिका मेंVARCHAR रों रूप में अच्छी तरह चर लंबाई विधि का उपयोग करने के लिए।)
भौतिक संग्रहण विधि सूचकांक विशेष रूप से महत्वपूर्ण है, जो टेबल तुलना में एक अलग कहानी है। MyISAM दोनोंCHAR और VARCHAR कॉलम के लिए अंतरिक्ष संपीड़न का उपयोग करता है, जिसका अर्थ है कि छोटे डेटा दोनों ही मामलों में सूचकांक में कम स्थान लें।
VARCHAR
InnoDB की InnoDB भंडारण, अधिकांश अन्य वर्तमान रिलेशनल डेटाबेस की तरह, एक और अधिक परिष्कृत तंत्र का उपयोग करता है। VARCHAR कॉलम जिनकी अधिकतम चौड़ाई 768 बाइट से कम है, इनलाइन को चौड़ाई से मेल खाने वाले कमरे के साथ इनलाइन संग्रहित किया जाएगा। अधिक सही here:
प्रत्येक गैर-शून्य चर लंबाई क्षेत्र के लिए, रिकॉर्ड हैडर एक या दो बाइट में स्तंभ की लंबाई में शामिल है। दो बाइट केवल होंगे यदि कॉलम का हिस्सा ओवरफ्लो पृष्ठों या में बाहरी रूप से संग्रहीत किया जाता है तो अधिकतम लंबाई 255 बाइट से अधिक हो जाती है और वास्तविक लंबाई 127 बाइट से अधिक हो जाती है। बाहरी रूप से संग्रहीत कॉलम के लिए, दो-बाइट लंबाई आंतरिक रूप से संग्रहीत भाग की लंबाई और 20-बाइट पॉइंटर बाहरी रूप से संग्रहीत भाग को इंगित करती है। आंतरिक भाग 768 बाइट्स है, इसलिए लंबाई 768 + 20 है। 20-बाइट पॉइंटर कॉलम की वास्तविक लंबाई संग्रहीत करता है।
InnoDB वर्तमान में ऊपर वर्णित अनुसार MyISAM के विपरीत, इसकी अनुक्रमणिका में अंतरिक्ष संपीड़न नहीं करता है। तथापि
सवाल
ऊपर कीसभी वापस सिर्फ एक implementational विस्तार भी है कि संस्करणों के बीच बदल सकते हैं। CHAR और VARCHAR के बीच वास्तविक अंतर अर्थपूर्ण है, और VARCHAR(20) और VARCHAR(50) के बीच एक भी है। यह सुनिश्चित करके कि VARCHAR(20) में 30 वर्ण स्ट्रिंग को स्टोर करने का कोई तरीका नहीं है, डेटाबेस विभिन्न प्रोसेसर और अनुप्रयोगों के लिए जीवन को आसान और बेहतर परिभाषित करता है जो इसे अनुमानित व्यवहार समाधान में एकीकृत करता है। यह एक बड़ा सौदा है।
व्यक्तिगत नामों के बारे में विशेष रूप से, this question आपको कुछ व्यावहारिक मार्गदर्शन दे सकता है। 70 यूटीएफ -8 अक्षरों से अधिक पूर्ण नाम वाले लोग वैसे भी परेशानी में हैं।
हां, यह वास्तव में वचरर का पूरा बिंदु है। टेक्स्ट जितना लंबा होता है उतना ही स्थान लेता है।
यदि आपके पास CHAR (50) था, तो यह 50 बाइट्स (या वर्ण) लेगा, इससे कोई फर्क नहीं पड़ता कि डेटा वास्तव में कितना छोटा है (यह आमतौर पर रिक्त स्थान से गद्देदार होगा)।
क्या कोई मुझे कारण बता सकता है?
क्योंकि लोगों ने सोचा कि यह बहुत बेकार पैडिंग स्टोर करने के लिए अपर्याप्त था, उन्होंने वचरर का आविष्कार किया।
यह वास्तव में "बेकार पैडिंग" से थोड़ा अधिक जटिल है: एक अक्षर (4) में '' foo '' से 'foo'' कैसे बताना है? –
सच है। की तरह। कुछ लोगों के लिए यह महत्वपूर्ण हो सकता है।जब मैं इसे लाता हूं तो आमतौर पर मुझे बहुत सारे डाउनवॉट मिलते हैं (आमतौर पर ओरेकल के खाली तारों के इलाज के निर्णय के संदर्भ में, लेकिन मैं उस एप्लिकेशन डिज़ाइन पर सवाल करता हूं जिसे '' foo '' और 'foo' (जैसा कि आप इस टिप्पणी धागे से देख सकते हैं, उद्धरण यहां एक संभावित समाधान भी हो सकता है, या आप किसी अन्य चीज़ के साथ पैड कर सकते हैं जिसका उपयोग अन्यथा नहीं किया जाता है)। – Thilo
CHAR के बारे में सकारात्मक जानकारी देने के लिए: यह निश्चित-लंबाई के रिकॉर्ड की अनुमति देता है। कुछ विशेष प्रयोजनों के लिए महत्वपूर्ण हो सकता है। – Thilo
The manual कहता है:
CHAR और VARCHAR प्रकार लंबाई है कि आप संग्रहीत करना चाहते हैं वर्णों की अधिकतम संख्या को इंगित करता है के साथ घोषणा की जाती है। (...)
CHAR के विपरीत, VARCHAR मूल्यों एक एक बाइट या दो-बाइट लंबाई उपसर्ग के साथ साथ डेटा के रूप में जमा हो जाती है। लंबाई उपसर्ग मूल्य में बाइट्स की संख्या इंगित करता है। यदि कॉल 255 बाइट्स से अधिक की आवश्यकता हो तो मानों को 255 बाइट्स से अधिक की आवश्यकता होने पर, एक लम्बाई बाइट का उपयोग करता है, तो दो लंबाई बाइट्स की आवश्यकता होती है।
सूचना है कि VARCHAR (255) नहीं VARCHAR (256) के समान है।
यह सिद्धांत है। habeebperwad पता चलता है, एक पंक्ति की वास्तविक पदचिह्न पर (इंजन) पृष्ठ आकार और (हार्ड डिस्क) ब्लॉक आकार निर्भर करता है।
यह एक तार्किक * सीमा * (उदा। बीओ नियम या "सुरक्षा") लगाता है। कृपया एसओ खोजें - यह पहले आया है और आम तौर पर लौ-युद्ध बहस में समाप्त होता है। –
@rabudde: क्या आप इसके बारे में निश्चित हैं? क्या आप एक संदर्भ दे सकते हैं? मैं ** बहुत ** आश्चर्यचकित हूं अगर परिभाषित लंबाई इंडेक्स में वर्चुअल कॉलम के रूप में रखी गई थी (अब 'char' एक अलग बात है)। कोई डीबीएमएस जो मुझे पता है इंडेक्स में पूरी लंबाई स्टोर करता है - लेकिन फिर MySQL हमेशा आश्चर्य के लिए अच्छा है। –
@pst, a_horse_with_no_name: आप सही हैं, मैं एक अन्य तथ्य (यूटीएफ 8 और इंडेक्स) के बारे में उलझन में था, और यह बिल्कुल सही बात है, एक बहुत बड़ी 'वर्कर' लंबाई का परिणाम अस्थायी या अस्थायी तालिकाओं पर संचालन पर खराब प्रदर्शन हो सकता है (O'Reilly से उच्च प्रदर्शन MySQL में संदर्भित) – rabudde