Inget DBMS jag känner till har någon "optimering" som gör en VARCHAR med en 2^n längd presterar bättre än en med max längd som inte är en potens av 2.
Jag tror att tidiga SQL Server-versioner faktiskt behandlade en VARCHAR med längd 255 annorlunda än en med högre maxlängd. Jag vet inte om detta fortfarande är fallet.
För nästan alla DBMS bestäms den faktiska lagringen som krävs endast av antalet tecken du lägger in i den, inte max längd du definierar. Så ur en lagringssynpunkt (och troligen också en prestanda) spelar det ingen roll om du deklarerar en kolumn som VARCHAR(100) eller VARCHAR(500) .
Du bör se max längd som anges för en VARCHAR kolumn som ett slags begränsning (eller affärsregel) snarare än en teknisk/fysisk sak.
För PostgreSQL är den bästa inställningen att använda text utan en längdbegränsning och en CHECK CONSTRAINT som begränsar antalet tecken till vad ditt företag än behöver.
Om det kravet ändras går det mycket snabbare att ändra kontrollbegränsningen än att ändra tabellen (eftersom tabellen inte behöver skrivas om)
Detsamma kan tillämpas för Oracle och andra - i Oracle skulle det vara VARCHAR(4000) istället för text fastän.
Jag vet inte om det finns en fysisk lagringsskillnad mellan VARCHAR(max) och t.ex. VARCHAR(500) i SQL Server. Men uppenbarligen finns det en prestandapåverkan när du använder varchar(max) jämfört med varchar(8000) .
Se denna länk (upplagt av Erwin Brandstetter som en kommentar)
Redigera 2013-09-22
Angående bigowns kommentar:
I Postgres-versioner före 9.2 (som inte var tillgängligt när jag skrev det första svaret) gjorde en ändring av kolumndefinitionen skriv om hela tabellen, se t.ex. här . Sedan 9.2 är detta inte längre fallet och ett snabbt test bekräftade att ökningen av kolumnstorleken för en tabell med 1,2 miljoner rader verkligen bara tog 0,5 sekunder.
För Oracle verkar detta vara sant också, att döma av den tid det tar att ändra ett stort bords varchar kolumn. Men jag kunde inte hitta någon referens för det.
För MySQL säger manualen
"I de flesta fall ALTER TABLE gör en tillfällig kopia av originaltabellen ". Och mina egna tester bekräftar att:kör en ALTER TABLE på en tabell med 1,2 miljoner rader (samma som i mitt test med Postgres) att öka storleken på en kolumn tog 1,5 minuter. I MySQL kan du dock inte använd "lösningen" för att använda en kontrollbegränsning för att begränsa antalet tecken i en kolumn.
För SQL Server kunde jag inte hitta ett tydligt uttalande om detta men exekveringstiden för att öka storleken på en varchar kolumnen (återigen tabellen med 1,2 miljoner rader från ovan) indikerar att nej omskrivning sker.
Redigera 2017-01-24
Jag verkar ha (åtminstone delvis) fel om SQL Server. Se det här svaret från Aaron Bertrand
som visar att den deklarerade längden på en nvarchar eller varchar kolumner gör en enorm skillnad för prestandan.