Geen enkel DBMS dat ik ken heeft enige "optimalisatie" die een VARCHAR . zal maken met een 2^n lengte presteert beter dan een met een max lengte die geen macht van 2 is.
Ik denk dat vroege versies van SQL Server eigenlijk een VARCHAR . behandelden met lengte 255 anders dan een met een hogere maximale lengte. Ik weet niet of dit nog steeds zo is.
Voor bijna alle DBMS wordt de daadwerkelijke benodigde opslagruimte alleen bepaald door het aantal tekens dat u erin stopt, niet de max lengte die u definieert. Dus vanuit een opslagoogpunt (en hoogstwaarschijnlijk ook een prestatie), maakt het geen verschil of u een kolom declareert als VARCHAR(100) of VARCHAR(500) .
Je zou de max . moeten zien lengte opgegeven voor een VARCHAR kolom als een soort beperking (of bedrijfsregel) in plaats van een technisch/fysiek iets.
Voor PostgreSQL is de beste setup om text te gebruiken zonder lengtebeperking en een CHECK CONSTRAINT dat het aantal tekens beperkt tot wat uw bedrijf nodig heeft.
Als die vereiste verandert, is het wijzigen van de controlebeperking veel sneller dan het wijzigen van de tabel (omdat de tabel niet opnieuw hoeft te worden geschreven)
Hetzelfde kan worden toegepast voor Oracle en anderen - in Oracle zou het VARCHAR(4000) . zijn in plaats van text hoewel.
Ik weet niet of er een fysiek opslagverschil is tussen VARCHAR(max) en bijv. VARCHAR(500) in SQL-server. Maar blijkbaar is er een prestatie-impact bij het gebruik van varchar(max) in vergelijking met varchar(8000) .
Zie deze link (gepost door Erwin Brandstetter als commentaar)
Bewerken 22-09-2013
Wat betreft de opmerking van Bigown:
In Postgres-versies vóór 9.2 (die niet beschikbaar was toen ik het eerste antwoord schreef) een wijziging in de kolomdefinitie deed herschrijf de hele tabel, zie b.v. hier . Sinds 9.2 is dit niet meer het geval en een snelle test bevestigde dat het vergroten van de kolomgrootte voor een tabel met 1,2 miljoen rijen inderdaad slechts 0,5 seconde duurde.
Voor Oracle lijkt dit ook waar te zijn, te oordelen naar de tijd die nodig is om de varchar van een grote tafel te wijzigen kolom. Maar ik kon daar geen referentie voor vinden.
Voor MySQL zegt de handleiding
"In de meeste gevallen ALTER TABLE maakt een tijdelijke kopie van de originele tabel ". En mijn eigen tests bevestigen dat:het uitvoeren van een ALTER TABLE op een tafel met 1,2 miljoen rijen (hetzelfde als in mijn test met Postgres) duurde het 1,5 minuut om de kolom groter te maken. In MySQL kunt u echter niet gebruik de "oplossing" om een controlebeperking te gebruiken om het aantal tekens in een kolom te beperken.
Voor SQL Server kon ik hier geen duidelijke verklaring over vinden, maar de uitvoeringstijd om de grootte van een varchar te vergroten kolom (opnieuw de 1,2 miljoen rijen tabel van boven) geeft aan dat nee herschrijven vindt plaats.
Bewerk 24-01-2017
Het lijkt erop dat ik (althans gedeeltelijk) ongelijk had over SQL Server. Zie dit antwoord van Aaron Bertrand
dat laat zien dat de gedeclareerde lengte van een nvarchar of varchar kolommen maakt een enorm verschil voor de prestaties.