Dies hängt ganz von der verwendeten DBMS-Engine ab. SQL selbst schreibt nicht vor, wie Dinge physisch gespeichert werden, sondern nur, wie sie logisch gesehen werden.
Beispielsweise kann Ihr DBMS Speicherplatz in der Zeile für die maximale Größe sowie einige zusätzliche Bytes zum Speichern der Länge zuweisen. In diesem Fall gäbe es einen großen Unterschied zwischen varchar(10) und varchar(1000) da Sie ziemlich viel Platz pro Zeile verschwenden würden.
Alternativ kann es einen Pufferpool für varchar verwenden Daten und speichern nur die Länge und die "Startadresse" des Pufferpools in der Zeile. In diesem Fall würde jede einzelne Zeile identisch große Informationen für ein varchar speichern Spalte, unabhängig von ihrer Größe, aber es würde einen zusätzlichen Schritt geben, um die tatsächlichen Daten in dieser Spalte zu extrahieren (nach dem Link zum Pufferpool).
Der Grund, warum Sie ein varchar verwenden genau deshalb heißt es varchar . Es ermöglicht Ihnen, Datenelemente mit variabler Größe zu speichern. Typischerweise char(10) gibt Ihnen zehn Zeichen, egal was, und füllt es mit Leerzeichen auf, wenn Sie etwas kürzeres einfügen. Sie können nachgestellte Leerzeichen beim Extrahieren abschneiden, aber das funktioniert nicht so gut, wenn die Daten, die Sie speichern möchten, tatsächlich "hello " sind , mit ein nachgestelltes Leerzeichen, das beibehalten werden soll.
Eine anständige DBMS-Engine kann entscheiden, einen Kompromiss einzugehen, abhängig von der maximalen Größe des varchar Säule. Bei kurzen könnte es einfach inline in der Zeile gespeichert werden und die zusätzlichen Bytes für die Größe verbrauchen.
Längeres varchar Spalten könnten in einen separaten Pufferpool "ausgelagert" werden, um sicherzustellen, dass das Zeilenlesen effizient bleibt (zumindest bis Sie brauchen das große varchar Spalte jedenfalls).
Sie müssen die Frage für Ihr spezifisches DBMS erneut stellen, um eine gezieltere Antwort zu erhalten.
Oder, ganz ehrlich, konstruieren Sie Ihre Datenbank so, dass sie nur die maximale Größe speichert. Wenn Sie wissen, dass es 10 ist, dann varchar(1000) ist eine Verschwendung. Wenn Sie in Zukunft die Spalte vergrößern müssen, das ist die Zeit dafür, und nicht jetzt (siehe YAGNI
). ).
Für MySQL sollten Sie sich Chapter 14 Storage Engines
der Online-Dokumentation.
Es deckt die verschiedenen Speicher-Engines (wie InnoDB und MyISAM) ab, die MySQL verwendet, und wenn Sie genau genug hinschauen, können Sie sehen, wie die Informationen physisch gespeichert werden.
Beispielsweise ist in MyISAM das Vorhandensein von Daten variabler Länge in einer Tabelle (varchar enthalten) bedeutet normalerweise dynamische Tabellen
. Dies folgt einem Schema, das ungefähr dem oben erwähnten Pufferpoolkonzept entspricht, mit dem Vorteil, dass weniger Platz für Spalten mit variabler Größe verschwendet wird, und dem Nachteil, dass Zeilen fragmentiert werden können.
Das andere Speicherformat (abgesehen vom komprimierten Format, da es eigentlich nur für schreibgeschützte Tabellen verwendet wird) ist statisches Format , wobei Daten in einer einzelnen physischen Zeile gespeichert werden.
Informationen zu den physikalischen Strukturen von InnoDB finden Sie unter hier . Je nachdem, ob Sie das Antelope- oder das Barracuda-Dateiformat verwenden, landen Sie in der Situation „Alle Informationen sind eine physische Zeile“ oder „Pufferpool“, ähnlich der MyISAM-Unterscheidung zwischen dynamisch und statisch.
