Kein mir bekanntes DBMS hat eine "Optimierung", die einen VARCHAR erstellt mit einem 2^n Länge besser abschneiden als eine mit max Länge, die keine Zweierpotenz ist.
Ich denke, dass frühe SQL Server-Versionen tatsächlich einen VARCHAR behandelt haben mit Länge 255 anders als eine mit größerer Maximallänge. Ich weiß nicht, ob das immer noch so ist.
Bei fast allen DBMS wird der tatsächlich benötigte Speicherplatz nur durch die Anzahl der eingegebenen Zeichen bestimmt, nicht durch max Länge, die Sie definieren. Aus Speichersicht (und höchstwahrscheinlich auch aus Performancesicht) macht es also keinen Unterschied, ob Sie eine Spalte als VARCHAR(100) deklarieren oder VARCHAR(500) .
Sie sollten das max sehen für einen VARCHAR bereitgestellte Länge Spalte als eine Art Einschränkung (oder Geschäftsregel) und nicht als technische/physikalische Sache.
Für PostgreSQL ist die beste Einrichtung die Verwendung von text ohne Längenbeschränkung und CHECK CONSTRAINT Dadurch wird die Anzahl der Zeichen auf die Anforderungen Ihres Unternehmens begrenzt.
Wenn sich diese Anforderung ändert, ist das Ändern der Check-Einschränkung viel schneller als das Ändern der Tabelle (weil die Tabelle nicht neu geschrieben werden muss)
Dasselbe gilt für Oracle und andere - in Oracle wäre es VARCHAR(4000) statt text obwohl.
Ich weiß nicht, ob es einen physischen Speicherunterschied zwischen VARCHAR(max) gibt und z.B. VARCHAR(500) im SQL-Server. Aber anscheinend gibt es eine Auswirkung auf die Leistung, wenn varchar(max) verwendet wird im Vergleich zu varchar(8000) .
Siehe diesen Link (von Erwin Brandstetter als Kommentar gepostet)
Bearbeitet am 22.09.2013
Zu Bigowns Kommentar:
In Postgres-Versionen vor 9.2 (die nicht verfügbar waren, als ich die ursprüngliche Antwort schrieb) wurde eine Änderung an der Spaltendefinition tat schreibe die ganze Tabelle um, siehe z.B. hier . Seit 9.2 ist dies nicht mehr der Fall und ein Schnelltest bestätigte, dass das Erhöhen der Spaltengröße für eine Tabelle mit 1,2 Millionen Zeilen tatsächlich nur 0,5 Sekunden dauerte.
Für Oracle scheint dies auch zuzutreffen, gemessen an der Zeit, die benötigt wird, um den varchar einer großen Tabelle zu ändern Säule. Aber ich konnte keine Referenz dafür finden.
Für MySQL sagt das Handbuch
"In den meisten Fällen ALTER TABLE erstellt eine temporäre Kopie der Originaltabelle ". Und meine eigenen Tests bestätigen das:Ausführen eines ALTER TABLE Auf einer Tabelle mit 1,2 Millionen Zeilen (dasselbe wie in meinem Test mit Postgres) dauerte es 1,5 Minuten, um die Größe einer Spalte zu erhöhen. In MySQL ist dies jedoch nicht möglich Verwenden Sie die "Problemumgehung", um eine Prüfbeschränkung zu verwenden, um die Anzahl der Zeichen in einer Spalte zu begrenzen.
Für SQL Server konnte ich keine klare Aussage dazu finden, aber die Ausführungszeit, um die Größe eines varchar zu erhöhen Spalte (wieder die 1,2-Millionen-Zeilen-Tabelle von oben) gibt an, dass nein Überschreiben erfolgt.
Bearbeitet am 24.01.2017
Scheint, als hätte ich mich (zumindest teilweise) in Bezug auf SQL Server geirrt. Siehe diese Antwort von Aaron Bertrand
das zeigt, dass die deklarierte Länge eines nvarchar oder varchar Spalten macht einen großen Unterschied für die Leistung.
