Žádný DBMS, o kterém vím, nemá žádnou "optimalizaci", která by vytvořila VARCHAR s 2^n délka má lepší výkon než jeden s max délka, která není mocninou 2.
Myslím, že rané verze SQL Serveru ve skutečnosti zacházely s VARCHAR s délkou 255 jinak než s vyšší maximální délkou. Nevím, jestli tomu tak stále je.
U téměř všech DBMS je skutečné požadované úložiště určeno pouze počtem znaků, které do něj vložíte, nikoli max délka, kterou určíte. Takže z hlediska úložiště (a s největší pravděpodobností také z hlediska výkonu) nezáleží na tom, zda sloupec deklarujete jako VARCHAR(100) nebo VARCHAR(500) .
Měli byste vidět max délka poskytnutá pro VARCHAR sloupec jako druh omezení (nebo obchodní pravidlo) spíše než jako technická/fyzická věc.
Pro PostgreSQL je nejlepší nastavení použít text bez omezení délky a CHECK CONSTRAINT to omezuje počet znaků na cokoliv, co vaše firma vyžaduje.
Pokud se tento požadavek změní, je změna kontrolního omezení mnohem rychlejší než změna tabulky (protože tabulku není nutné přepisovat)
Totéž lze použít pro Oracle a další - v Oracle by to bylo VARCHAR(4000) místo text ačkoli.
Nevím, zda existuje rozdíl ve fyzickém úložišti mezi VARCHAR(max) a např. VARCHAR(500) v SQL Serveru. Ale zjevně existuje vliv na výkon při použití varchar(max) ve srovnání s varchar(8000) .
Viz tento odkaz (vydal Erwin Brandstetter jako komentář)
Upravit 22. 9. 2013
Pokud jde o bigownův komentář:
Ve verzích Postgres před 9.2 (která nebyla k dispozici, když jsem psal první odpověď) se změna definice sloupce udělala přepište celou tabulku, viz např. zde . Od verze 9.2 to již neplatí a rychlý test potvrdil, že zvětšení velikosti sloupce u tabulky s 1,2 miliony řádků skutečně trvalo pouze 0,5 sekundy.
Zdá se, že to platí i pro Oracle, soudě podle času, který zabere změna varchar velkého stolu sloupec. Ale nenašel jsem na to žádný odkaz.
Pro MySQL příručka říká
"Ve většině případů ALTER TABLE vytvoří dočasnou kopii původní tabulky ". A mé vlastní testy to potvrzují:spuštění ALTER TABLE na tabulce s 1,2 milionu řádků (stejně jako v mém testu s Postgres) trvalo zvětšení velikosti sloupce 1,5 minuty. V MySQL však nemůžete použijte "řešení" k použití kontrolního omezení k omezení počtu znaků ve sloupci.
Pro SQL Server jsem nemohl najít jasné prohlášení o tom, ale dobu provádění pro zvětšení velikosti varchar sloupec (opět tabulka 1,2 milionu řádků shora) znamená, že ne dojde k přepsání.
Upravit 24. 1. 2017
Zdá se, že jsem se (alespoň částečně) mýlil s SQL Serverem. Viz tuto odpověď od Aarona Bertranda
což ukazuje, že deklarovaná délka nvarchar nebo varchar sloupců je obrovský rozdíl pro výkon.