Musisz zdać sobie sprawę z kompromisów używania CHAR vs VARCHAR
W przypadku pól CHAR alokujesz dokładnie to, co dostajesz. Na przykład CHAR (15) przydziela i przechowuje 15 bajtów, bez względu na to, jak postacie umieszczasz w polu. Manipulowanie ciągami znaków jest proste i jednoznaczne, ponieważ wielkość pola danych jest całkowicie przewidywalna.
Dzięki polom VARCHAR otrzymujesz zupełnie inną historię. Na przykład VARCHAR (15) faktycznie dynamicznie przydziela do 16 bajtów, do 15 na dane i co najmniej 1 dodatkowy bajt do przechowywania długości danych. Jeśli masz ciąg „hello” do zapisania, który zajmie 6 bajtów, a nie 5. Manipulowanie ciągiem zawsze musi przeprowadzać sprawdzanie długości we wszystkich przypadkach.
Kompromis jest bardziej widoczny, gdy wykonujesz dwie rzeczy:
1. Przechowywanie milionów lub miliardów wierszy
2. Indeksowanie kolumn, które są albo CHAR albo VARCHAR
TRADEOFF # 1
Oczywiście VARCHAR ma tę zaletę, że dane o zmiennej długości utworzyłyby mniejsze wiersze, a tym samym mniejsze pliki fizyczne.
TRADEOFF # 2
Ponieważ pola CHAR wymagają mniejszej manipulacji ciągiem ze względu na stałe szerokości pól, wyszukiwanie indeksów względem pola CHAR jest średnio o 20% szybsze niż w przypadku pól VARCHAR. To nie jest żadna hipoteza z mojej strony. Książka MySQL Database Design and Tuning wykonała coś cudownego na stole MyISAM, aby to udowodnić. Przykład w książce zrobił coś takiego:
ALTER TABLE tblname ROW_FORMAT=FIXED;
Ta dyrektywa zmusza VARCHAR do zachowywania się jak CHAR. Zrobiłem to podczas mojej poprzedniej pracy w 2007 roku i wziąłem tabelę 300 GB i przyspieszyłem wyszukiwanie indeksów o 20%, nie zmieniając niczego innego. Działa jak opublikowano. Jednak stworzył stół prawie dwukrotnie większy, ale to po prostu wraca do kompromisu nr 1.
Możesz przeanalizować przechowywane dane, aby zobaczyć, co MySQL zaleca do definicji kolumny. Po prostu uruchom następujące polecenie dla dowolnej tabeli:
SELECT * FROM tblname PROCEDURE ANALYSE();
Spowoduje to przejście całej tabeli i zalecenie definicji kolumn dla każdej kolumny na podstawie zawartych w niej danych, minimalnych wartości pól, maksymalnych wartości pól i tak dalej. Czasami musisz po prostu zachować zdrowy rozsądek przy planowaniu CHAR vs VARCHAR. Oto dobry przykład:
Jeśli przechowujesz adresy IP, maska takiej kolumny ma maksymalnie 15 znaków (xxx.xxx.xxx.xxx). W mgnieniu oka przeskoczyłbym na CHAR (15), ponieważ długości adresów IP nie będą się tak bardzo różnić, a dodatkowa złożoność operacji na łańcuchach kontrolowana przez dodatkowy bajt. Nadal można wykonać ANALIZĘ PROCEDURY () przeciwko takiej kolumnie. Może nawet polecić VARCHAR. W tym przypadku moje pieniądze byłyby nadal na CHAR zamiast VARCHAR.
Problemy z CHAR vs VARCHAR można rozwiązać tylko poprzez odpowiednie planowanie. Z wielką mocą wiąże się wielka odpowiedzialność (banał, ale prawda)