Detta beror helt på vilken DBMS-motor som används. SQL i sig föreskriver inte hur saker lagras fysiskt, bara hur de ses logiskt.
Till exempel kan din DBMS allokera utrymme i raden för maximal storlek, plus några extra byte för att lagra längden. I så fall skulle det vara stor skillnad mellan varchar(10) och varchar(1000) eftersom du skulle slösa mycket utrymme per rad.
Alternativt kan den använda en buffertpool för varchar data och lagra endast längden och buffertpoolens "startadress" i raden. I så fall skulle varje enskild rad lagra information av identisk storlek för en varchar kolumn oavsett storlek, men det skulle finnas ett extra steg för att extrahera de faktiska uppgifterna i den kolumnen (följ länken till buffertpoolen).
Anledningen till att du använder en varchar är exakt varför den heter varchar . Det låter dig lagra dataelement av variabel storlek. Vanligtvis char(10) ger dig tio tecken, oavsett vad, fyller den med mellanslag om du infogar något kortare. Du kan trimma av efterföljande utrymmen när du extraherar det, men det kommer inte att fungera så bra om data du vill lagra faktiskt är "hello " , med ett efterföljande utrymme du vill bevaras.
En anständig DBMS-motor kan välja att göra en avvägning beroende på den maximala storleken på varchar kolumn. För korta kan den bara lagra den inline i raden och konsumera de extra byten för storleken.
Längre varchar kolumner kan "outsourcas" till en separat buffertpool för att säkerställa att radläsningen hålls effektiv (åtminstone tills du behöver den stora varchar kolumn i alla fall).
Vad du behöver göra är att ställa frågan igen för ditt specifika DBMS för att få ett mer riktat svar.
Eller, ärligt talat, konstruera din databas så att den bara lagrar den maximala storleken. Om du vet att det är 10, då varchar(1000) är ett slöseri. Om du i framtiden behöver förstora kolumnen, det är det dags att göra det, snarare än nu (se YAGNI
).
För MySQL bör du titta på Chapter 14 Storage Engines
av onlinedokumentationen.
Den täcker de olika lagringsmotorerna (som InnoDB och MyISAM) som MySQL använder och när du tittar tillräckligt djupt kan du se hur informationen lagras fysiskt.
Till exempel, i MyISAM, förekomsten av data med variabel längd i en tabell (varchar ingår) betyder vanligtvis dynamiska tabeller
. Detta följer ett schema ungefär analogt med buffertpoolskonceptet jag nämnde ovan, med fördelen att mindre utrymme slösas bort för kolumner med varierande storlek och nackdelen att rader kan bli fragmenterade.
Det andra lagringsformatet (rabatterar komprimerat format eftersom det egentligen bara används för skrivskyddade tabeller) är statisk en , där data lagras i en enda fysisk rad.
Information om InnoDB fysiska strukturer finns här . Beroende på om du använder filformatet Antelope eller Barracuda, hamnar du i situationen "all information är en fysisk rad" eller "buffertpool", liknande MyISAM-skillnaden mellan dynamisk och statisk.