MySQL VARCHAR और TEXT डेटा प्रकारों में क्या अंतर है?

संस्करण 5.0.3 के बाद (जिसने VARCHAR को 65,535 बाइट्स की अनुमति दी और अनुगामी रिक्त स्थान को बंद कर दिया), क्या इन दो डेटा प्रकारों के बीच कोई बड़ा अंतर है?

मैं अंतरों की सूची पढ़ रहा था और केवल दो नोट हैं:

BLOB और TEXT कॉलम पर अनुक्रमित के लिए, आपको एक सूचकांक उपसर्ग लंबाई निर्दिष्ट करनी होगी। CHAR और VARCHAR के लिए, एक उपसर्ग लंबाई वैकल्पिक है। खंड 7.5.1, "कॉलम इंडेक्स" देखें।

तथा

BLOB और TEXT कॉलम में DEFAULT मान नहीं हो सकते।

इसलिए, TEXT डेटाटाइप पर इन दो सीमाओं के कारण, आप इसे varchar (65535) पर क्यों इस्तेमाल करेंगे? क्या एक के बाद एक प्रदर्शन में गड़बड़ी होती है?

mysql database-design datatypes

— डेरेक डाउनी
स्रोत

जब आप डेटा में 65535 से अधिक वर्ण चाहते हैं?

— BlackICE

यहाँ varchar और text के बीच बेंचमार्क के बारे में एक बहुत अच्छा मंच धागा है: http://forums.mysql.com/read.php?24,105964,105964

— विभाजित

क्योंकि वहाँ की सूची वास्तव में स्पष्ट विवरणों को बिछाने का एक अच्छा काम करती है, और क्योंकि आपके पास पहले से ही मतभेदों की सूची है, मुझे यकीन नहीं है कि यह उस तरह का प्रश्न है जो हमें डीबीए पर चाहिए। क्या कोई कारण है कि आपने जिस सूची का हवाला दिया है और जो कारण बताए हैं, वे इस मामले में काफी अच्छे नहीं हैं ? अन्यथा मैं VTC लिए जा रहा हूँ

— jcolebrand

मैंने अपने प्रश्न को अपडेट किया, लेकिन एक स्पष्ट कारण है कि मुझे यकीन नहीं है कि दूसरे पर एक का प्रदर्शन है। सुनिश्चित नहीं हैं कि अन्य स्पष्ट कारण नहीं हैं

— डेरेक डाउनी

तो क्या यह उचित है कि आप जो पूछ रहे हैं वह दूसरे के प्रदर्शन की विशेषता है?

— jcolebrand

विभाजित कुछ जानकारी है कि बुनियादी मुद्दा बताते से जुड़ा हुआ (वहाँ प्रदर्शन अंतर है), लेकिन यह आसान है कि एक हमेशा अन्य की तुलना में बेहतर है कहने के लिए पर्याप्त नहीं है। (अन्यथा, दोनों होने का कोई कारण नहीं होगा।) इसके अलावा, MyISM में, वर्च के लिए 64k अधिकतम आकार प्रति फ़ील्ड नहीं है - यह प्रति रिकॉर्ड है।

मूल रूप से, डेटाबेस रिकॉर्ड में तार को स्टोर करने के 4 तरीके हैं:

तय लंबाई
सी-स्टाइल स्ट्रिंग्स (स्ट्रिंग के अंत में एक NULL या समान वर्ण के साथ चिह्नित)
पास्कल स्टाइल स्ट्रिंग्स (लंबाई इंगित करने के लिए कुछ बाइट्स, फिर स्ट्रिंग)
पॉइंटर्स (स्ट्रिंग को कहीं और स्टोर करें)

MyISM VARCHAR के लिए # 3 के समान कुछ का उपयोग करता है, और TEXT के लिए एक हाइब्रिड दृष्टिकोण जहां यह रिकॉर्ड में स्ट्रिंग की शुरुआत को संग्रहीत करता है, फिर स्ट्रिंग के बाकी कहीं और। InnoDB VARCHAR के लिए समान है, लेकिन रिकॉर्ड के बाहर पूरा पाठ क्षेत्र संग्रहीत करता है।

1 और 4 के साथ, रिकॉर्ड में सामान हमेशा एक ही लंबाई है, इसलिए इसे छोड़ना आसान है यदि आपको स्ट्रिंग की आवश्यकता नहीं है, लेकिन इसके बाद सामान की आवश्यकता है। शॉर्ट स्ट्रिंग्स के लिए # 2 और # 3 दोनों बहुत बुरे नहीं हैं ... # 2 को मार्कर की तलाश में रहना है, जबकि # 3 आगे छोड़ सकते हैं ... क्योंकि स्ट्रिंग्स लंबे समय तक मिलती हैं, # 2 इस विशेष उपयोग के लिए खराब हो जाती है मामला।

यदि आपको वास्तव में स्ट्रिंग को पढ़ने की आवश्यकता है, # 4 धीमा है, जैसा कि आपको रिकॉर्ड पढ़ना है, तो स्ट्रिंग को पढ़ें जो डिस्क पर कहीं और संग्रहीत किया जा सकता है, केवल इस आधार पर कि डेटाबेस इसे कैसे संभालता है। # 1 हमेशा बहुत सीधा होता है, और फिर से आप इसी तरह के मुद्दों में भाग लेते हैं, जहां # 2 के लिए बदतर हो जाता है, स्ट्रिंग बहुत लंबी होती है, जबकि # 3 बहुत छोटे तारों के लिए # 2 से थोड़ा खराब होता है, लेकिन जितना लंबा हो उतना बेहतर होता है।

तब भंडारण आवश्यकताएं होती हैं ... # 1 हमेशा एक निश्चित लंबाई होती है, इसलिए यदि अधिकतम तार अधिकतम लंबाई नहीं होते हैं तो यह ब्लोट हो सकता है। # 2 में 1 अतिरिक्त बाइट है; # 3 आमतौर पर 2 अतिरिक्त बाइट्स होते हैं यदि अधिकतम लंबाई = 255, 4 अतिरिक्त बाइट्स यदि एक 64k अधिकतम। # 4 में पॉइंटर की लंबाई होती है, साथ ही आमतौर पर # 3 के नियम भी।

MySQL 5.1 के भीतर विशिष्ट कार्यान्वयन के लिए, MyISM राज्य के लिए डॉक्स :

एक सच्चे VARCHAR प्रकार के लिए समर्थन; VARCHAR कॉलम एक या दो बाइट्स में संग्रहीत लंबाई के साथ शुरू होता है।
VARCHAR कॉलम के साथ तालिकाओं में निश्चित या गतिशील पंक्ति की लंबाई हो सकती है।
एक तालिका में VARCHAR और CHAR कॉलम की लंबाई का योग 64KB तक हो सकता है।

जबकि InnoDB के लिए :

रिकॉर्ड हेडर के चर-लंबाई वाले हिस्से में NULL कॉलम को इंगित करने के लिए थोड़ा वेक्टर होता है। यदि अनुक्रमणिका में स्तंभों की संख्या NULL हो सकती है, तो बिट वेक्टर CEILING (N / 8) बाइट्स पर कब्जा कर लेता है। (उदाहरण के लिए, यदि 9 से 15 स्तंभों में से कहीं भी NULL हो सकता है, तो बिट वेक्टर दो बाइट्स का उपयोग करता है।) कॉलम जो NULL हैं, वे इस वेक्टर में बिट के अलावा अन्य स्थान पर कब्जा नहीं करते हैं। शीर्ष लेख के चर-लंबाई वाले हिस्से में भी चर-लंबाई स्तंभों की लंबाई होती है। कॉलम की अधिकतम लंबाई के आधार पर, प्रत्येक लंबाई में एक या दो बाइट्स होते हैं। यदि अनुक्रमणिका के सभी स्तंभ NULL नहीं हैं और उनकी निश्चित लंबाई है, तो रिकॉर्ड शीर्ष लेख में कोई चर-लंबाई वाला भाग नहीं है।
प्रत्येक गैर-NULL चर-लंबाई फ़ील्ड के लिए, रिकॉर्ड शीर्षलेख में एक या दो बाइट्स में स्तंभ की लंबाई होती है। दो बाइट्स केवल तभी आवश्यक होंगे जब स्तंभ का हिस्सा बाहरी पेजों में बाह्य रूप से संग्रहीत किया जाए या अधिकतम लंबाई 255 बाइट्स से अधिक हो और वास्तविक लंबाई 127 बाइट्स से अधिक हो। बाह्य रूप से संग्रहीत कॉलम के लिए, दो-बाइट की लंबाई आंतरिक रूप से संग्रहीत भाग की लंबाई और बाह्य रूप से संग्रहीत भाग के लिए 20-बाइट सूचक को इंगित करती है। आंतरिक भाग 768 बाइट्स है, इसलिए लंबाई 768 + 20 है। 20-बाइट पॉइंटर कॉलम की सही लंबाई संग्रहीत करता है।

...

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

— जो
स्रोत

थ्रेड से जुड़े लिंक में कहा गया है कि MySQL स्टोर ब्लूब

— माइकल मिओर जूल

नाइटिक ... सभी व्यावहारिक उद्देश्यों के लिए, या तो इंजन में एक पंक्ति पर 64KB की कोई सीमा नहीं है। LONGTEXTऔर LONGBLOBबिंदु में एक मामला है। सी-स्टाइल स्ट्रिंग्स का उपयोग MySQL (जो मुझे पता है) द्वारा कहीं नहीं किया जाता है। InnoDB एक 'हाइब्रिड' दृष्टिकोण का उपयोग करता है, लेकिन यह अधिक जटिल है, पंक्ति आकार, row_format, आदि के आधार पर "निश्चित" लंबाई में स्ट्रिंग्स को संग्रहीत करना लगभग कभी भी उचित नहीं होता है सिवाय इसके कि जब वे वास्तव में एक स्थिर लंबाई (देश_कोड, zip_code, आदि) हों । InnoDB 4 है ROW_FORMATs; पाठ उनमें से केवल 1 या 2 पर चर्चा करता है।

— रिक जेम्स

जब किसी SELECT को एक अस्थायी तालिका (जैसे परिणामों को क्रमबद्ध करने के लिए) बनाने की आवश्यकता होती है, तो वह या तो एक MEMORY तालिका, या एक MyISAM तालिका बनाएगी। स्मृति अधिक कुशल है। MEMORY पर प्रतिबंध हैं - एक को TEXT और BLOB को अस्वीकार करना है। इसलिए, एक चयन VARCHAR की तुलना में पाठ के साथ धीमी गति से चल सकता है ।

— रिक जेम्स
स्रोत