Cela dépend entièrement du moteur SGBD utilisé. SQL lui-même n'impose pas la manière dont les éléments sont stockés physiquement, mais uniquement la manière dont ils sont vus logiquement.
Par exemple, votre SGBD peut allouer de l'espace dans la ligne pour la taille maximale, plus quelques octets supplémentaires pour stocker la longueur. Dans ce cas, il y aurait une grande différence entre varchar(10) et varchar(1000) car vous perdriez pas mal d'espace par ligne.
Alternativement, il peut utiliser un pool de mémoire tampon pour le varchar data et ne stocke que la longueur et "l'adresse de départ" du pool de mémoire tampon dans la ligne. Dans ce cas, chaque ligne stockerait des informations de taille identique pour un varchar quelle que soit sa taille, mais il y aurait une étape supplémentaire pour extraire les données réelles dans cette colonne (en suivant le lien vers le pool de mémoire tampon).
La raison pour laquelle vous utilisez un varchar c'est exactement pourquoi il s'appelle varchar . Il permet de stocker des éléments de données de taille variable. Typiquement, char(10) vous donne dix caractères, quoi qu'il arrive, en le remplissant d'espaces si vous insérez quelque chose de plus court. Vous pouvez supprimer les espaces de fin au fur et à mesure que vous les extrayez, mais cela ne fonctionnera pas aussi bien si les données que vous souhaitez stocker sont en fait "hello " , avec un espace de fin que vous souhaitez conserver.
Un moteur de SGBD décent peut décider de faire un compromis en fonction de la taille maximale du varchar colonne. Pour les plus courts, il pourrait simplement le stocker en ligne dans la ligne et consommer les octets supplémentaires pour la taille.
varchar plus long les colonnes peuvent être "externalisées" vers un pool de mémoire tampon séparé pour garantir l'efficacité de la lecture des lignes (au moins jusqu'à ce que vous ayez besoin le grand varchar colonne, de toute façon).
Ce que vous devez faire est de poser à nouveau la question pour votre SGBD spécifique afin d'obtenir une réponse plus ciblée.
Ou, en toute honnêteté, concevez votre base de données pour ne stocker que la taille maximale. Si vous savez que c'est 10, alors varchar(1000) est un déchet. Si, à l'avenir, vous devez agrandir la colonne, ça est le moment de le faire, plutôt que maintenant (voir YAGNI
).
Pour MySQL, vous voudrez regarder Chapter 14 Storage Engines
de la documentation en ligne.
Il couvre les différents moteurs de stockage (tels que InnoDB et MyISAM) utilisés par MySQL et, en regardant assez en profondeur, vous pouvez voir comment les informations sont physiquement stockées.
Par exemple, dans MyISAM, la présence de données de longueur variable dans une table (varchar inclus) signifie généralement tables dynamiques
. Cela suit un schéma à peu près analogue au concept de pool de mémoire tampon que j'ai mentionné ci-dessus, avec l'avantage que moins d'espace est gaspillé pour les colonnes de taille variable et l'inconvénient que les lignes peuvent se fragmenter.
L'autre format de stockage (hormis le format compressé puisqu'il n'est réellement utilisé que pour les tables en lecture seule) est le statique , où les données sont stockées dans une seule ligne physique.
Des informations sur les structures physiques InnoDB peuvent être trouvées ici . Selon que vous utilisez le format de fichier Antelope ou Barracuda, vous vous retrouvez avec la situation "toutes les informations sont une ligne physique" ou "pool de mémoire tampon", similaire à la distinction MyISAM entre dynamique et statique.
