मुझे पता है कि कोई डीबीएमएस कोई "अनुकूलन" नहीं है जो VARCHAR . बना देगा 2^n . के साथ लंबाई max के साथ एक से बेहतर प्रदर्शन करती है लंबाई जो 2 की शक्ति नहीं है।
मुझे लगता है कि प्रारंभिक SQL सर्वर संस्करणों ने वास्तव में VARCHAR . का इलाज किया था लंबाई 255 के साथ एक से अधिक अधिकतम लंबाई के साथ अलग। मुझे नहीं पता कि क्या अभी भी ऐसा है।
लगभग सभी DBMS के लिए, आवश्यक वास्तविक संग्रहण केवल आपके द्वारा इसमें डाले गए वर्णों की संख्या से निर्धारित होता है, न कि max से। लंबाई आप परिभाषित करते हैं। तो भंडारण के दृष्टिकोण से (और संभवतः एक प्रदर्शन भी), इससे कोई फर्क नहीं पड़ता कि आप कॉलम को VARCHAR(100) घोषित करते हैं या नहीं या VARCHAR(500) .
आपको max देखना चाहिए एक VARCHAR . के लिए प्रदान की गई लंबाई स्तंभ एक तकनीकी/भौतिक चीज़ के बजाय एक प्रकार की बाधा (या व्यावसायिक नियम) के रूप में।
PostgreSQL के लिए सबसे अच्छा सेटअप text . का उपयोग करना है लंबाई प्रतिबंध के बिना और CHECK CONSTRAINT जो आपके व्यवसाय के लिए आवश्यक वर्णों की संख्या को सीमित करता है।
यदि वह आवश्यकता बदल जाती है, तो चेक बाधा को बदलना तालिका को बदलने की तुलना में बहुत तेज़ है (क्योंकि तालिका को फिर से लिखने की आवश्यकता नहीं है)
वही Oracle और अन्य के लिए लागू किया जा सकता है - Oracle में यह VARCHAR(4000) . होगा text . के बजाय हालांकि।
मुझे नहीं पता कि VARCHAR(max) . के बीच कोई भौतिक संग्रहण अंतर है या नहीं और जैसे VARCHAR(500) एसक्यूएल सर्वर में। लेकिन स्पष्ट रूप से varchar(max) . का उपयोग करते समय एक प्रदर्शन प्रभाव पड़ता है varchar(8000) . की तुलना में .
देखें यह लिंक (एक टिप्पणी के रूप में इरविन ब्रैंडस्टेटर द्वारा पोस्ट किया गया)
2013-09-22 संपादित करें
बिगाउन की टिप्पणी के संबंध में:
9.2 से पहले के पोस्टग्रेज संस्करणों में (जो तब उपलब्ध नहीं था जब मैंने प्रारंभिक उत्तर लिखा था) कॉलम परिभाषा में बदलाव किया पूरी तालिका को फिर से लिखें, उदाहरण देखें। यहां . 9.2 के बाद से अब ऐसा नहीं है और एक त्वरित परीक्षण ने पुष्टि की कि 1.2 मिलियन पंक्तियों वाली तालिका के लिए कॉलम का आकार बढ़ाना वास्तव में केवल 0.5 सेकंड लेता है।
Oracle के लिए यह सच भी लगता है, एक बड़ी तालिका के varchar को बदलने में लगने वाले समय को देखते हुए कॉलम। लेकिन मुझे इसका कोई संदर्भ नहीं मिला।
MySQL के लिए मैनुअल कहता है
"ज्यादातर मामलों में, ALTER TABLE मूल तालिका की अस्थायी प्रतिलिपि बनाता है ". और मेरे अपने परीक्षण इस बात की पुष्टि करते हैं कि:ALTER TABLE . चलाना 1.2 मिलियन पंक्तियों वाली एक मेज पर (पोस्टग्रेज के साथ मेरे परीक्षण के समान) एक स्तंभ के आकार को बढ़ाने में 1.5 मिनट लगे। हालांकि MySQL में आप नहीं कर सकते हैं एक कॉलम में वर्णों की संख्या को सीमित करने के लिए चेक बाधा का उपयोग करने के लिए "समाधान" का उपयोग करें।
SQL सर्वर के लिए मुझे इस पर एक स्पष्ट विवरण नहीं मिला लेकिन varchar के आकार को बढ़ाने के लिए निष्पादन समय मिला कॉलम (फिर से ऊपर से 1.2 मिलियन पंक्तियों की तालिका) इंगित करता है कि नहीं पुनर्लेखन होता है।
2017-01-24 संपादित करें
ऐसा लगता है कि मैं (कम से कम आंशिक रूप से) SQL सर्वर के बारे में गलत था। देखें एरॉन बर्ट्रेंड का यह जवाब
यह दर्शाता है कि nvarchar . की घोषित लंबाई या varchar कॉलम प्रदर्शन के लिए एक बड़ा अंतर बनाता है।
