Żaden DBMS, o którym wiem, nie ma żadnej „optymalizacji”, która utworzy VARCHAR z 2^n długość działa lepiej niż jeden z max długość, która nie jest potęgą 2.
Myślę, że wczesne wersje SQL Server faktycznie traktowały VARCHAR o długości 255 inaczej niż o większej długości maksymalnej. Nie wiem, czy nadal tak jest.
Dla prawie wszystkich DBMS, rzeczywista wymagana pamięć jest określana tylko przez liczbę znaków, które w niej umieścisz, a nie przez max długość, którą definiujesz. Tak więc z punktu widzenia przechowywania (i prawdopodobnie również wydajności), nie ma znaczenia, czy zadeklarujesz kolumnę jako VARCHAR(100) lub VARCHAR(500) .
Powinieneś zobaczyć max długość podana dla VARCHAR kolumna jako rodzaj ograniczenia (lub reguły biznesowej), a nie rzecz techniczna/fizyczna.
W przypadku PostgreSQL najlepszą konfiguracją jest użycie text bez ograniczenia długości i CHECK CONSTRAINT to ogranicza liczbę znaków do tego, czego wymaga Twoja firma.
Jeśli to wymaganie ulegnie zmianie, zmiana ograniczenia sprawdzającego jest znacznie szybsza niż zmiana tabeli (ponieważ tabeli nie trzeba przepisywać)
To samo można zastosować do Oracle i innych - w Oracle będzie to VARCHAR(4000) zamiast text chociaż.
Nie wiem, czy istnieje fizyczna różnica w pamięci masowej między VARCHAR(max) i m.in. VARCHAR(500) w SQL Server. Ale najwyraźniej istnieje wpływ na wydajność podczas korzystania z varchar(max) w porównaniu do varchar(8000) .
Zobacz ten link (opublikowane przez Erwina Brandstettera jako komentarz)
Edytuj 22.09.2013
Odnośnie komentarza bigown:
W wersjach Postgresa przed 9.2 (które nie były dostępne, gdy pisałem początkową odpowiedź) zmiana definicji kolumny zrobiła przepisz na nowo całą tabelę, zobacz m.in. tutaj . Od wersji 9.2 tak już nie jest, a szybki test potwierdził, że zwiększenie rozmiaru kolumny dla tabeli z 1,2 miliona wierszy rzeczywiście zajęło tylko 0,5 sekundy.
W przypadku Oracle wydaje się to być prawdą, sądząc po czasie potrzebnym do zmiany varchar dużej tabeli kolumna. Ale nie mogłem znaleźć żadnego odniesienia do tego.
W przypadku MySQL instrukcja mówi
"W większości przypadków ALTER TABLE tworzy tymczasową kopię oryginalnej tabeli ". A moje własne testy potwierdzają to:uruchomienie ALTER TABLE na stole z 1,2 miliona wierszy (tyle samo co w moim teście z Postgresem) zwiększenie rozmiaru kolumny zajęło 1,5 minuty. Jednak w MySQL możesz nie użyj "obejścia", aby użyć ograniczenia sprawdzającego w celu ograniczenia liczby znaków w kolumnie.
W przypadku SQL Server nie mogłem znaleźć jasnego oświadczenia na ten temat, ale czas wykonania, aby zwiększyć rozmiar varchar kolumna (ponownie tabela 1,2 miliona wierszy powyżej) wskazuje, że nie ma miejsce przepisywanie.
Edytuj 24.01.2017
Wygląda na to, że (przynajmniej częściowo) się myliłem co do SQL Server. Zobacz tę odpowiedź Aarona Bertranda
który pokazuje, że zadeklarowana długość nvarchar lub varchar kolumny mają ogromny wpływ na wydajność.
