Нито една СУБД, за която познавам, няма "оптимизация", която ще направи VARCHAR с 2^n дължина се представя по-добре от едно с max дължина, която не е степен на 2.
Мисля, че ранните версии на SQL Server всъщност третираха VARCHAR с дължина 255 различно от тази с по-висока максимална дължина. Не знам дали това все още е така.
За почти всички СУБД действителното хранилище, което се изисква, се определя само от броя на символите, които сте поставили в него, а не от max дължина, която определяте. Така че от гледна точка на съхранението (и най-вероятно и производителността), няма никаква разлика дали декларирате колона като VARCHAR(100) или VARCHAR(500) .
Трябва да видите max дължина, предоставена за VARCHAR колона като вид ограничение (или бизнес правило), а не като техническо/физическо нещо.
За PostgreSQL най-добрата настройка е да използвате text без ограничение на дължината и CHECK CONSTRAINT което ограничава броя на знаците до това, което изисква вашият бизнес.
Ако това изискване се промени, промяната на ограничението за проверка е много по-бърза от промяната на таблицата (тъй като таблицата не се нуждае от пренаписване)
Същото може да се приложи за Oracle и други - в Oracle би било VARCHAR(4000) вместо text все пак.
Не знам дали има разлика във физическото съхранение между VARCHAR(max) и напр. VARCHAR(500) в SQL Server. Но очевидно има влияние върху производителността при използване на varchar(max) в сравнение с varchar(8000) .
Вижте тази връзка (публикувано от Erwin Brandstetter като коментар)
Редактиране на 22.09.2013
Относно коментара на bigown:
Във версиите на Postgres преди 9.2 (която не беше налична, когато написах първоначалния отговор) промяна в дефиницията на колоната направи пренапишете цялата таблица, вижте напр. тук . От 9.2 това вече не е така и бърз тест потвърди, че увеличаването на размера на колоната за таблица с 1,2 милиона реда наистина отнема само 0,5 секунди.
За Oracle това изглежда също е вярно, съдейки по времето, необходимо за промяна на varchar на голяма таблица колона. Но не можах да намеря референция за това.
За MySQL в ръководството пише
"В повечето случаи ALTER TABLE прави временно копие на оригиналната таблица ". И моите собствени тестове потвърждават това:стартиране на ALTER TABLE на таблица с 1,2 милиона реда (същото като в моя тест с Postgres) за увеличаване на размера на колона отне 1,5 минути. В MySQL обаче можете не използвайте "заобикалящото решение", за да използвате ограничение за проверка, за да ограничите броя на знаците в колона.
За SQL Server не можах да намеря ясно изявление за това, но времето за изпълнение за увеличаване на размера на varchar колона (отново таблицата с 1,2 милиона реда отгоре) показва, че не се извършва пренаписване.
Редактиране на 24.01.2017
Изглежда, че греша (поне частично) относно SQL Server. Вижте този отговор от Aaron Bertrand
което показва, че декларираната дължина на nvarchar или varchar колони прави огромна разлика за производителността.
