varchar (255) या varchar (256)?


21

क्या मुझे टेबल डिज़ाइन करते समय उपयोग करना चाहिए varchar(255)या करना चाहिए varchar(256)? मैंने सुना है कि एक बाइट का उपयोग कॉलम की लंबाई, या मेटाडेटा को स्टोर करने के लिए किया जाता है।

क्या इस बिंदु पर अब कोई फर्क पड़ता है?

मैंने इंटरनेट पर कुछ पोस्ट देखीं, हालांकि वे ओरेकल और MySQL पर लागू होते हैं।

हमारे पास Microsoft SQL Server 2016 एंटरप्राइज़ संस्करण है, यह इस वातावरण पर कैसे लागू होता है?

अब उदाहरण के लिए, क्या होगा यदि मैंने अपने ग्राहकों को उदाहरण के लिए रखने के लिए कहा, 256 के बजाय 255 वर्णों का एक पाठ विवरण, क्या कोई अंतर है? मैंने क्या पढ़ा "अधिकतम 255 वर्णों के साथ, DBMS क्षेत्र में डेटा की लंबाई को इंगित करने के लिए एक बाइट का उपयोग करने का विकल्प चुन सकता है। यदि सीमा 256 या अधिक थी, तो दो बाइट्स की आवश्यकता होगी।" क्या ये सच है?


FYI करें: यह सवाल MSDN मंचों पर क्रॉस-पोस्ट किया गया था: social.msdn.microsoft.com/Forums/sqlserver/en-US/…
Solomon Rutzky

जवाबों:


36

प्रत्येक कॉलम को उचित आकार दें। प्रत्येक स्तंभ के लिए "मानक" आकार का उपयोग न करें। यदि आपको केवल 30 वर्णों की आवश्यकता है, तो ऐसा कॉलम क्यों बनाएं जो 255 को संभाल सके? मुझे खुशी है कि आप varchar(max)अपने स्ट्रिंग कॉलम के लिए उपयोग करने की वकालत नहीं कर रहे हैं।

यह विशेष रूप से विवेकपूर्ण सलाह है यदि आपको कभी भी एक कॉलम को इंडेक्स करने की आवश्यकता होती है, या यदि आप एक कॉलम को प्राथमिक कुंजी के रूप में उपयोग कर रहे हैं और इसमें विदेशी संदर्भ हैं। SQL सर्वर क्वेरी प्रसंस्करण के लिए अनुमानित स्मृति आवश्यकताओं को समझने के लिए क्वेरी ऑप्टिमाइज़र में प्रत्येक स्तंभ के आकार का उपयोग करता है। ओवरसाइज़ किए गए कॉलम प्रदर्शन के लिए हानिकारक हो सकते हैं।

ओवरसाइज़ करने वाले स्तंभों पर अनुक्रमणिका उत्पन्न होने के परिणामस्वरूप त्रुटियां उत्पन्न हो सकती हैं:

CREATE TABLE dbo.WideIndex
(
    col1 varchar(255) NOT NULL
    , col2 varchar(255) NOT NULL
    , col3 varchar(600) NOT NULL    
);

CREATE INDEX IX_WideIndex_01
ON dbo.WideIndex (col1, col2, col3);

इस चेतावनी में परिणाम के ऊपर सूचकांक बनाने का प्रयास:

चेतावनी! अधिकतम मुख्य लंबाई 900 बाइट्स है। सूचकांक 'IX_WideIndex_01' की अधिकतम लंबाई 1110 बाइट्स है। बड़े मूल्यों के कुछ संयोजन के लिए, सम्मिलित / अद्यतन कार्रवाई विफल हो जाएगी।

900 बाइट्स क्लस्टर इंडेक्स (और SQL सर्वर 2012 और पुराने पर गैर-क्लस्टर इंडेक्स) के लिए अधिकतम महत्वपूर्ण आकार है। 1700 बाइट्स SQL ​​सर्वर के नए संस्करणों पर गैर-संकुल इंडेक्स के लिए अधिकतम कुंजी आकार है। यदि आप एक जेनेरिक चौड़ाई वाले कॉलम (जैसे 255) को डिज़ाइन करते हैं, तो आप इस चेतावनी में उम्मीद से कहीं अधिक बार भाग सकते हैं।

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

सबसे पहले, हम एक तालिका बनाएँगे जहाँ हम विभिन्न आकारों के स्तंभों को संग्रहीत कर सकते हैं:

IF OBJECT_ID(N'dbo.varchartest', N'U') IS NOT NULL
DROP TABLE dbo.varchartest;
GO

CREATE TABLE dbo.varchartest
(
    varchar30 varchar(30) NOT NULL
    , varchar255 varchar(255) NOT NULL
    , varchar256 varchar(256) NOT NULL
);

अब हम एक पंक्ति डालेंगे:

INSERT INTO dbo.varchartest (varchar30, varchar255, varchar256)
VALUES (REPLICATE('1', 30), REPLICATE('2', 255), REPLICATE('3', 256));

यह क्वेरी अनिर्धारित, और असमर्थित, फ़ंक्शंस का उपयोग करती है sys.fn_RowDumpCrackerऔर sys.fn_PhyslocCrackerतालिका के बारे में कुछ दिलचस्प विवरण दिखाने के लिए:

SELECT rdc.*
    , plc.*
FROM dbo.varchartest vct
CROSS APPLY  sys.fn_RowDumpCracker(%%rowdump%%) rdc
CROSS APPLY sys.fn_physlocCracker(%%physloc%%) plc

आउटपुट इस तरह दिखेगा:

╔═════════════════════╦════════════╦═════════╦════ ══════╦══════════════════════════╦══════════╦═════ ════════╦═════════════╦═════════╦═════════╦═══════ ══╗
║ partition_id
╠═════════════════════╬════════════╬═════════╬════ ══════╬══════════════════════════╬══════════╬═════ ════════╬═════════════╬═════════╬═════════╬═══════ ══╣
║ 1729382263096344576 30 varchar30 ║ 1 29 0 ║ 0 ║ 0 ║ 0 ║ 0 ║ 30 ║ 1 12 1912 ║ 0 22
║ 1729382263096344576 25 varchar255 ║ 1 ║ 0 ║ 0 ║ 0 ║ 0 ║ 0 ║ 255 ║ 1 12 1912 ║ 0 22
║ 1729382263096344576 25 varchar256 ║ 1 ║ 0 ║ 0 ║ 0 ║ 0 ║ 0 ║ 256 ║ 1 12 1912 ║ 0 22
╚═════════════════════╩════════════╩═════════╩════ ══════╩══════════════════════════╩══════════╩═════ ════════╩═════════════╩═════════╩═════════╩═══════ ══╝

जैसा कि आप देख सकते हैं, InRowLengthप्रत्येक मूल्य के लिए प्रत्येक पंक्ति के भौतिक भंडारण स्थान के साथ दिखाया गया है - "file_id", "page_id", और "slot_id"।

यदि हम क्वेरी परिणामों से ऊपर file_idऔर page_idमान लेते हैं और DBCC PAGEउनके साथ चलते हैं, तो हम वास्तविक भौतिक पृष्ठ सामग्री देख सकते हैं:

DBCC TRACEON (3604); --send display to the client
DBCC PAGE (tempdb, 1, 1912, 3); --database, file_id, page_id, 3 to show page contents
DBCC TRACEOFF (3604);--reset display back to the error log

मेरी मशीन के परिणाम हैं:

पृष्ठ: (१: १ ९ १२)


बफर:


BUF @ 0x00000000FF5B2E80

bpage = 0x0000000024130000 bhash = 0x0000000000000000 bpageno = (1: 1912)
bdbid = 2 breferences = 0 bcputicks = 0
bsampleCount = 0 bUse1 = 32497 bstat = 0x10b
ब्लॉग = 0x212121cc bnext = 0x0000000000000000          

पेज हैडर:


पेज @ 0x0000000024130000

m_pageId = (1: 1912) m_headerVersion = 1 m_type = 1
m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x8000
m_objId (AllocUnitId.idObj) = 98834 m_indexId (AllocUnitId.idInd) = 7936
मेटाडाटा: ऑलोक्युनीट = 2233785421652951040                              
मेटाडाटा: पार्टिशन आई डी = 1945555045333008384 मेटाडेटा: इंडेक्सआईड = 0
मेटाडेटा: ObjectId = 34099162 m_prevPage = (0: 0) m_nextPage = (0: 0)
pminlen = 4 m_slotCnt = 1 m_freeCnt = 7538
m_freeData = 652 m_reservedCnt = 0 m_lsn = (35: 210971: 362)
m_xactReserved = 0 m_xdesId = (0: 0) m_ghostRecCnt = 0
m_tornBits = 0 DB Frag ID = 1                      

आवंटन की स्थिति

GAM (1: 2) = आवंटित SGAM (1: 3) = आवंटित नहीं किया गया PFS (1: 1) = 0x41 आवंटित 50_PCT_FULL
DIFF (1: 6) = नहीं बदला गया ML (1: 7) = MIN_LOGGED नहीं           

स्लॉट 0 ऑफसेट 0x60 लंबाई 556

रिकॉर्ड प्रकार = PRIMARY_RECORD रिकॉर्ड गुण = NULL_BITMAP VARIABLE_COLUMNS
रिकॉर्ड आकार = 556                   
मेमोरी डंप @ 0x000000005145A060

0000000000000000: 30000400 03000003 002d002c 012c0231 31313131 31113 .........,।, 11111
0000000000000014: 31313131 31313131 31313131 31313131 31313131 11111111111111111111
0000000000000028: 31313131 31323232 32323232 32323232 32323232 111112222222222222
000000000000003C: 32323232 32323232 32323232 32323232 32323232 222222222222222222
0000000000000050: 32323232 32323232 32323232 32323232 32323232 22222222222222222222
0000000000000064: 32323232 32323232 32323232 32323232 32323232 22222222222222222222
0000000000000078: 32323232 32323232 32323232 32323232 32323232 22222222222222222222
000000000000008C: 32323232 32323232 32323232 32323232 32323232 222222222222222222
00000000000000A0: 32323232 32323232 32323232 32323232 32323232 222222222222222222
00000000000000B4: 32323232 32323232 32323232 32323232 32323232 222222222222222222
00000000000000C8: 32323232 32323232 32323232 32323232 32323232 222222222222222222
00000000000000DC: 32323232 32323232 32323232 32323232 32323232 22222222222222222222
00000000000000F0: 32323232 32323232 32323232 32323232 32323232 222222222222222222
0000000000000104: 32323232 32323232 32323232 32323232 32323232 222222222222222222
0000000000000118: 32323232 32323232 32323232 32323232 32323232 222222222222222222
000000000000012C: 33333333 33333333 33333333 33333333 33333333 33333333333333333333
0000000000000140: 33333333 33333333 33333333 33333333 33333333 3333333333333333333333
0000000000000154: 33333333 33333333 33333333 33333333 33333333 33333333333333333333
0000000000000168: 33333333 33333333 33333333 33333333 33333333 33333333333333333333
000000000000017C: 33333333 33333333 33333333 33333333 33333333 33333333333333333333
0000000000000190: 33333333 33333333 33333333 33333333 33333333 3333333333333333333333
00000000000001A4: 33333333 33333333 33333333 33333333 33333333 33333333333333333333
00000000000001B8: 33333333 33333333 33333333 33333333 33333333 33333333333333333333
00000000000001CC: 33333333 33333333 33333333 33333333 33333333 33333333333333333333
00000000000001E0: 33333333 33333333 33333333 33333333 33333333 33333333333333333333
00000000000001F4: 33333333 33333333 33333333 33333333 33333333 33333333333333333333
0000000000000208: 33333333 33333333 33333333 33333333 33333333 33333333333333333333
000000000000021C: 33333333 33333333 33333333 33333333 3333333333333333

स्लॉट 0 कॉलम 1 ऑफसेट 0xf लंबाई 30 लंबाई (भौतिक) 30

varchar30 = 11111111111111111111111111111111                               

स्लॉट 0 कॉलम 2 ऑफसेट 0x2d लंबाई 255 लंबाई (भौतिक) 255

varchar255 = 222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222
22222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222
222222222222222222222222222222222222222222                               

स्लॉट 0 कॉलम 3 ऑफसेट 0x12c लंबाई 256 लंबाई (भौतिक) 256

varchar256 = 3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333
33333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333
3333333333333333333333333333333333333333333                              

16

दूसरों ने पहले ही बताया है कि लंबाई को संग्रहीत करने के लिए आवश्यक बाइट्स की संख्या निर्धारित है। मैं आपके प्रश्न में इस भाग पर ध्यान देना चाहता था:

क्या इस बिंदु पर अब कोई फर्क पड़ता है?

आपके पास एंटरप्राइज़ संस्करण के साथ टैग किया गया आपका प्रश्न है, जिसका अर्थ है कि आपके पास उचित मात्रा में डेटा होगा। अक्सर प्रति पंक्ति एक बाइट के अंतर वास्तव में बहुत ज्यादा मायने नहीं रखते हैं। उदाहरण के लिए, पूरी तरह से भरे VARCHAR(255)स्तंभ के साथ निम्न तालिका डिस्क पर 143176 KB स्थान लेती है:

DROP TABLE IF EXISTS dbo.V255_FULL;

CREATE TABLE dbo.V255_FULL (
    ID1 BIGINT NOT NULL,
    ID2 BIGINT NOT NULL,
    V255 VARCHAR(255)
);

INSERT INTO dbo.V255_FULL WITH (TABLOCK)
SELECT TOP (500000) 0, 0, REPLICATE('A', 255)
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

EXEC sp_spaceused 'V255_FULL';

परिणाम:

╔═══════════╦══════════════════════╦═══════════╦═══════════╦════════════╦════════╗
   name             rows          reserved     data     index_size  unused 
╠═══════════╬══════════════════════╬═══════════╬═══════════╬════════════╬════════╣
 V255_FULL  500000                143176 KB  142888 KB  8 KB        280 KB 
╚═══════════╩══════════════════════╩═══════════╩═══════════╩════════════╩════════╝

चलो पूरी तरह से भरे हुए VARCHAR(256)कॉलम के साथ एक दूसरी तालिका बनाते हैं । वह प्रति पंक्ति कम से कम एक और बाइट लेने जा रहा है, है ना?

DROP TABLE IF EXISTS dbo.V256_FULL;

CREATE TABLE dbo.V256_FULL (
    ID1 BIGINT NOT NULL,
    ID2 BIGINT NOT NULL,
    V256 VARCHAR(256)
);

INSERT INTO dbo.V256_FULL WITH (TABLOCK)
SELECT TOP (500000) 0, 0, REPLICATE('A', 256)
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

EXEC sp_spaceused 'V256_FULL';

परिणाम:

╔═══════════╦══════════════════════╦═══════════╦═══════════╦════════════╦════════╗
   name             rows          reserved     data     index_size  unused 
╠═══════════╬══════════════════════╬═══════════╬═══════════╬════════════╬════════╣
 V256_FULL  500000                143176 KB  142888 KB  8 KB        280 KB 
╚═══════════╩══════════════════════╩═══════════╩═══════════╩════════════╩════════╝

यह सिर्फ इतना होता है कि दोनों तालिकाओं में समान मात्रा में जगह होती है। पंक्तियों की समान संख्या प्रत्येक 8k पेज पर फिट होती है। यह बहुत अच्छा है कि आप अपने आवेदन को अनुकूलित करने में समय व्यतीत करना चाहते हैं, लेकिन मुझे संदेह है कि आप अलग-अलग क्षेत्रों पर ध्यान केंद्रित कर रहे हैं।


7

Varchar के घोषित आकार का कोई प्रदर्शन प्रभाव नहीं है। डेटा को वास्तव में पेज संपीड़न या पंक्ति संपीड़न के साथ एक रोस्टोरेंट के रूप में संग्रहीत किया जा सकता है। क्लस्टर किए गए स्तंभ के रूप में, या स्मृति-अनुकूलित तालिका के रूप में। इनमें से प्रत्येक के अलग-अलग प्रदर्शन ट्रेड-ऑफ़ होंगे, लेकिन यह कभी मायने नहीं रखता कि आप एक varchar (255) या varchar (256) की घोषणा करते हैं।


9
@ डेविडबोर्न-माइक्रोसॉफ्ट नं, "वर्चर के घोषित आकार का कोई प्रदर्शन प्रभाव नहीं है" निश्चित रूप से सही नहीं है - डेटाटाइप आकार प्रश्नों के लिए मेमोरी ग्रांट को प्रभावित करता है। अधिक जानकारी के लिए brentozar.com/archive/2017/02/memory-grants-data-size देखें ।
ब्रेंट ओजार

6
इसे सरल रखने की कोशिश कर रहा है, और समय से पहले अनुकूलन को हतोत्साहित करता है।
डेविड ब्राउन - Microsoft
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.