it-swarm-eu.dev

Jaký je rozdíl mezi datovými typy MySQL VARCHAR a TEXT?

Po verzi 5.0.3 (která umožnila VARCHARu mít 65 535 bajtů a zastavit zkrácení koncových mezer) je mezi těmito dvěma datovými typy nějaký zásadní rozdíl?

Četl jsem seznam rozdílů a jediné dvě poznámky jsou:

Pro indexy ve sloupcích BLOB a TEXT musíte zadat délku předpony indexu. Pro CHAR a VARCHAR je délka předpony volitelná. Viz oddíl 7.5.1 - „Indexy sloupců“.

a

Sloupce BLOB a TEXT nemohou mít výchozí hodnoty.

Takže z důvodu těchto dvou omezení datového typu TEXT, proč byste je měli používat nad varcharem (65535)? Existují výkonnostní důsledky jednoho nad druhým?

19
Derek Downey

rozděleno spojené s některými informacemi, které vysvětlují základní problém (existují rozdíly ve výkonu), ale není dost jednoduché říci, že jeden je vždy lepší než ten druhý. (Jinak by neměl být důvod mít obojí.) Také v MyISM není maximální velikost 64k pro VARCHAR na pole - na záznam.

V zásadě existují 4 způsoby, jak ukládat řetězce do databázových záznamů:

  1. pevná délka
  2. Řetězce ve stylu C (na konci řetězce označené NULL nebo podobným znakem)
  3. Řetězce stylu Pascal (několik bajtů pro označení délky, potom řetězce)
  4. Ukazatele (řetězec uložte někde jinde)

MyISM používá pro VARCHAR něco podobného # 3 a hybridní přístup pro TEXT, kde ukládá začátek řetězce do záznamu a zbytek řetězce někde jinde. InnoDB je podobný pro VARCHAR, ale ukládá celé pole TEXT mimo záznam.

U 1 a 4 je obsah v záznamu vždy stejný, takže je snazší přeskočit, pokud řetězec nepotřebujete, ale potřebujete jej po něm. Oba # 2 a # 3 nejsou pro krátké řetězce příliš špatné ... # 2 musí stále hledat značku, zatímco # 3 může přeskočit dopředu ... jak se řetězce prodlužují, # 2 se pro toto konkrétní použití zhoršuje. případ.

Pokud skutečně potřebujete číst řetězec, # 4 je pomalejší, protože musíte číst záznam, pak si přečtěte řetězec, který by mohl být uložen jinde na disku, v závislosti na tom, jak s ním databáze nakládá. # 1 je vždy docela přímočará a znovu se setkáváte s podobnými problémy, kde pro # 2 je horší, čím delší je řetězec, zatímco # 3 je o něco horší než # 2 pro velmi malé řetězce, ale lepší, když se prodlužuje.

Pak jsou zde požadavky na úložiště ... # 1 je vždy pevná délka, takže může mít nadýmání, pokud většina řetězců není maximální délka. # 2 má 1 bajt navíc; # 3 má obvykle 2 další bajty, pokud je maximální délka = 255, 4 další bajty, pokud je maximální délka 64 kB. # 4 má délku ukazatele plus pravidla pro # 3.

Pro konkrétní implementace v MySQL 5.1 dokumenty pro stav MyISM :

  • Podpora skutečného typu VARCHAR; sloupec VARCHAR začíná délkou uloženou v jednom nebo dvou bajtech.
  • Tabulky se sloupci VARCHAR mohou mít pevnou nebo dynamickou délku řádku.
  • Součet délek sloupců VARCHAR a CHAR v tabulce může být až 64 kB.

Zatímco pro InnoDB :

  • Část záhlaví záznamu s proměnnou délkou obsahuje bitový vektor pro označení sloupců NULL. Pokud je počet sloupců v indexu, který může být NULL, N, bitový vektor zabírá CEILING (N/8) bajtů. (Například pokud existuje kdekoli od 9 do 15 sloupců, které mohou být NULL, bitový vektor používá dva bajty.) Sloupce, které jsou NULL, nezabírají jiné místo než bit v tomto vektoru. Část záhlaví s proměnnou délkou také obsahuje délky sloupců s proměnnou délkou. Každá délka trvá jeden nebo dva bajty, v závislosti na maximální délce sloupce. Pokud všechny sloupce v indexu NENÍ NULL a mají pevnou délku, záhlaví záznamu nemá žádnou část s proměnnou délkou.
  • Pro každé pole jiné než NULL s proměnnou délkou obsahuje záhlaví záznamu délku sloupce v jednom nebo dvou bajtech. Dva bajty budou nutné pouze v případě, že je část sloupce uložena externě na přetečených stránkách nebo pokud maximální délka přesahuje 255 bajtů a skutečná délka přesahuje 127 bajtů. U externě uloženého sloupce označuje dvoubajtová délka délku interně uložené části plus 20-bajtový ukazatel na externě uloženou část. Vnitřní část je 768 bajtů, takže délka je 768 + 20. Ukazatel 20 bajtů ukládá skutečnou délku sloupce.

...

jako při mnoha jiných věcech při práci s databázemi, pokud si nejste jisti, co je pro vaše potřeby nejlepší, zkuste to porovnat s podobnými daty a použitím a podívejte se, jak se chovají.

13
Joe

Když SELECT potřebuje vytvořit dočasnou tabulku (například pro třídění výsledků), vytvoří buď MEMORY tabulku, nebo MyISAM tabulku. MEMORY je efektivnější. Existují omezení pro MEMORY - jedním je zakázat TEXT a BLOB. Proto VYBRAT může běžet pomaleji s textem než VARCHAR.

2
Rick James