Nessun DBMS che conosco ha alcuna "ottimizzazione" che creerà un VARCHAR con un 2^n lunghezza si comporta meglio di uno con un max lunghezza che non è una potenza di 2.
Penso che le prime versioni di SQL Server trattassero effettivamente un VARCHAR con lunghezza 255 diversamente da uno con lunghezza massima superiore. Non so se è ancora così.
Per quasi tutti i DBMS, lo spazio di archiviazione effettivo richiesto è determinato solo dal numero di caratteri inseriti, non dal max lunghezza che definisci. Quindi dal punto di vista dello storage (e molto probabilmente anche delle prestazioni), non fa alcuna differenza se dichiari una colonna come VARCHAR(100) o VARCHAR(500) .
Dovresti vedere il max lunghezza fornita per un VARCHAR colonna come una sorta di vincolo (o regola aziendale) piuttosto che una cosa tecnico/fisica.
Per PostgreSQL la configurazione migliore consiste nell'usare text senza un limite di lunghezza e un CHECK CONSTRAINT che limita il numero di caratteri a qualsiasi cosa richieda la tua attività.
Se tale requisito cambia, modificare il vincolo di controllo è molto più veloce che modificare la tabella (perché non è necessario riscrivere la tabella)
Lo stesso può essere applicato per Oracle e altri:in Oracle sarebbe VARCHAR(4000) invece di text anche se.
Non so se c'è una differenza di archiviazione fisica tra VARCHAR(max) e ad es. VARCHAR(500) in SQL Server. Ma a quanto pare c'è un impatto sulle prestazioni quando si utilizza varchar(max) rispetto a varchar(8000) .
Vedi questo link (inviato da Erwin Brandstetter come commento)
Modifica 22-09-2013
Per quanto riguarda il commento di bigown:
Nelle versioni di Postgres precedenti alla 9.2 (che non era disponibile quando ho scritto la risposta iniziale) una modifica alla definizione della colonna fatto riscrivere l'intera tabella, vedere ad es. qui . Dalla versione 9.2 non è più così e un rapido test ha confermato che l'aumento della dimensione della colonna per una tabella con 1,2 milioni di righe richiedeva infatti solo 0,5 secondi.
Anche per Oracle questo sembra essere vero, a giudicare dal tempo necessario per modificare il varchar di un grande tavolo colonna. Ma non sono riuscito a trovare alcun riferimento per questo.
Per MySQL il manuale dice
"Nella maggior parte dei casi, ALTER TABLE esegue una copia temporanea della tabella originale ". E i miei test lo confermano:eseguire un ALTER TABLE su una tabella con 1,2 milioni di righe (lo stesso del mio test con Postgres) per aumentare le dimensioni di una colonna sono stati necessari 1,5 minuti. In MySQL invece non puoi usa la "soluzione alternativa" per utilizzare un vincolo di controllo per limitare il numero di caratteri in una colonna.
Per SQL Server non sono riuscito a trovare una dichiarazione chiara su questo, ma il tempo di esecuzione per aumentare la dimensione di un varchar colonna (di nuovo la tabella di 1,2 milioni di righe di cui sopra) indica che no avviene la riscrittura.
Modifica 24-01-2017
Sembra che mi sbagliassi (almeno in parte) su SQL Server. Vedi questa risposta di Aaron Bertrand
che mostra che la lunghezza dichiarata di un nvarchar o varchar le colonne fanno un'enorme differenza per le prestazioni.
