Ingen DBMS, jeg kender til, har nogen "optimering", der vil lave en VARCHAR med en 2^n længde yder bedre end én med en max længde, der ikke er en potens af 2.
Jeg tror, at tidlige SQL Server-versioner faktisk behandlede en VARCHAR med længde 255 anderledes end en med en højere maksimal længde. Jeg ved ikke, om dette stadig er tilfældet.
For næsten alle DBMS er det faktiske lager, der kræves, kun bestemt af antallet af tegn, du lægger i det, ikke max længde du definerer. Så fra et opbevaringssynspunkt (og sandsynligvis også en ydeevne), gør det ikke nogen forskel, om du erklærer en kolonne som VARCHAR(100) eller VARCHAR(500) .
Du bør se max længde angivet for en VARCHAR kolonne som en slags begrænsning (eller forretningsregel) snarere end en teknisk/fysisk ting.
For PostgreSQL er den bedste opsætning at bruge text uden en længdebegrænsning og en CHECK CONSTRAINT der begrænser antallet af tegn til det, din virksomhed kræver.
Hvis dette krav ændres, er det meget hurtigere at ændre kontrolbegrænsningen end at ændre tabellen (fordi tabellen ikke skal omskrives)
Det samme kan anvendes for Oracle og andre - i Oracle ville det være VARCHAR(4000) i stedet for text selvom.
Jeg ved ikke, om der er en fysisk lagerforskel mellem VARCHAR(max) og f.eks. VARCHAR(500) i SQL Server. Men tilsyneladende er der en præstationspåvirkning, når du bruger varchar(max) sammenlignet med varchar(8000) .
Se dette link (indsendt af Erwin Brandstetter som kommentar)
Rediger 2013-09-22
Angående bigowns kommentar:
I Postgres-versioner før 9.2 (som ikke var tilgængelig, da jeg skrev det første svar) gjorde en ændring af kolonnedefinitionen omskriv hele tabellen, se f.eks. her . Siden 9.2 er dette ikke længere tilfældet, og en hurtig test bekræftede, at det kun tog 0,5 sekunder at øge kolonnestørrelsen for en tabel med 1,2 millioner rækker.
For Oracle ser dette også ud til at være sandt, at dømme efter den tid, det tager at ændre et stort bords varchar kolonne. Men jeg kunne ikke finde nogen reference til det.
For MySQL siger manualen
"I de fleste tilfælde ALTER TABLE laver en midlertidig kopi af den originale tabel ". Og mine egne tests bekræfter det:at køre en ALTER TABLE på en tabel med 1,2 millioner rækker (det samme som i min test med Postgres) at øge størrelsen af en kolonne tog 1,5 minutter. I MySQL kan du dog ikke brug "løsningen" til at bruge en kontrolbegrænsning til at begrænse antallet af tegn i en kolonne.
For SQL Server kunne jeg ikke finde en klar erklæring om dette, men udførelsestiden for at øge størrelsen af en varchar kolonne (igen tabellen med 1,2 millioner rækker fra oven) angiver, at nej omskrivning finder sted.
Rediger 2017-01-24
Det ser ud til, at jeg tog (i det mindste delvist) fejl om SQL Server. Se dette svar fra Aaron Bertrand
der viser, at den erklærede længde af en nvarchar eller varchar kolonner gør en kæmpe forskel for præstationen.