Ciò dipende interamente dal motore DBMS utilizzato. Lo stesso SQL non impone il modo in cui le cose vengono archiviate fisicamente, ma solo come sono viste logicamente.
Ad esempio, il tuo DBMS può allocare spazio nella riga per la dimensione massima, più alcuni byte extra per memorizzare la lunghezza. In tal caso, ci sarebbe una grande differenza tra varchar(10) e varchar(1000) poiché sprecheresti un bel po' di spazio per riga.
In alternativa, può utilizzare un pool di buffer per varchar dati e memorizzare solo la lunghezza e l'"indirizzo iniziale" del pool di buffer nella riga. In tal caso, ogni singola riga conserverebbe informazioni di dimensioni identiche per un varchar colonna indipendentemente dalle sue dimensioni, ma ci sarebbe un passaggio aggiuntivo per estrarre i dati effettivi in quella colonna (seguendo il collegamento al pool di buffer).
Il motivo per cui usi un varchar è esattamente il motivo per cui si chiama varchar . Ti consente di memorizzare elementi di dati di dimensioni variabili. In genere, char(10) ti dà dieci caratteri, non importa cosa, riempiendolo di spazi se inserisci qualcosa di più breve. Puoi ritagliare gli spazi finali mentre lo estrai, ma non funzionerà così bene se i dati che desideri archiviare sono effettivamente "hello " , con uno spazio finale che vuoi preservare.
Un motore DBMS decente potrebbe decidere di fare un compromesso a seconda della dimensione massima del varchar colonna. Per quelli brevi, potrebbe semplicemente memorizzarlo in linea nella riga e consumare i byte extra per la dimensione.
varchar più lungo le colonne potrebbero essere "esternalizzate" in un pool di buffer separato per garantire che la lettura delle righe sia mantenuta efficiente (almeno fino a quando necessario il grande varchar colonna, comunque).
Quello che devi fare è porre nuovamente la domanda per il tuo DBMS specifico in modo da ottenere una risposta più mirata.
Oppure, in tutta onestà, progetta il tuo database per memorizzare solo la dimensione massima. Se sai che è 10, allora varchar(1000) è uno spreco. Se, in futuro, hai bisogno di ingrandire la colonna, quello è il momento di farlo, piuttosto che adesso (vedi YAGNI
).
Per MySQL, ti consigliamo di guardare Chapter 14 Storage Engines
della documentazione in linea.
Copre i vari motori di archiviazione (come InnoDB e MyISAM) utilizzati da MySQL e, guardando abbastanza in profondità, puoi vedere come le informazioni vengono archiviate fisicamente.
Ad esempio, in MyISAM, la presenza di dati di lunghezza variabile in una tabella (varchar incluso) di solito significa tabelle dinamiche
. Questo segue uno schema più o meno analogo al concetto di pool di buffer che ho menzionato sopra, con il vantaggio che viene sprecato meno spazio per colonne di dimensioni variabili e lo svantaggio che le righe possono essere frammentate.
L'altro formato di archiviazione (scontando il formato compresso poiché è realmente utilizzato solo per tabelle di sola lettura) è statico , dove i dati sono archiviati in un'unica riga fisica.
È possibile trovare informazioni sulle strutture fisiche di InnoDB qui . A seconda che utilizzi il formato di file Antelope o Barracuda, ti ritroverai con la situazione "tutte le informazioni sono una riga fisica" o "pool di buffer", simile alla distinzione MyISAM tra dinamico e statico.
