MySQL nabízí výběr úložných enginů. Fyzické úložiště dat závisí na úložišti.
MyISAM Storage of VARCHAR
V MyISAM VARCHAR s typicky zabírají pouze skutečnou délku řetězce plus jeden nebo dva bajty délky. To je praktické díky konstrukčnímu omezení MyISAM na zamykání tabulky na rozdíl od schopnosti zamykání řádků. Důsledky výkonu zahrnují kompaktnější profil mezipaměti, ale také komplikovanější (pomalejší) výpočet posunů záznamů.
(MyISAM vám ve skutečnosti poskytuje míru výběru mezi pevnou fyzickou velikostí řádku a proměnnou fyzickou velikostí řádků v závislosti na typech sloupců vyskytujících se v celé tabulce. Výskyt VARCHAR změní pouze výchozí metodu, ale přítomnost TEXT blob síly VARCHAR s ve stejné tabulce, chcete-li použít také metodu proměnné délky.)
Metoda fyzického ukládání je zvláště důležitá u indexů, což je jiný příběh než tabulky. MyISAM používá prostorovou kompresi pro obě CHAR a VARCHAR sloupce, což znamená, že kratší data v obou případech zabírají méně místa v indexu.
Úložiště InnoDB pro VARCHAR
InnoDB, stejně jako většina ostatních současných relačních databází, používá sofistikovanější mechanismus. VARCHAR sloupce, jejichž maximální šířka je menší než 768 bajtů, budou uloženy inline, přičemž vyhrazená místnost bude odpovídat této maximální šířce. Přesněji zde
:
InnoDB v současné době neprovádí kompresi prostoru ve svých indexech, což je opak MyISAM, jak je popsáno výše.
Zpět k otázce
Vše výše uvedené je však pouze detail implementace, který se může mezi verzemi dokonce měnit. Skutečný rozdíl mezi CHAR a VARCHAR je sémantický, stejně jako ten mezi VARCHAR(20) a VARCHAR(50) . Zajištěním, že neexistuje způsob, jak uložit řetězec 30 znaků do VARCHAR(20) , databáze usnadňuje a lépe definuje život pro různé procesory a aplikace, které údajně integruje do předvídatelně se chovajícího řešení. To je velký problém.
Pokud jde konkrétně o osobní jména, tato otázka vám může poskytnout praktické rady. Lidé s celým jménem delším než 70 znaků UTF-8 mají každopádně potíže.