char kontra varchar

[weecioo]

no i kupa z masłem Panowie

Wziąłem się za testy. Tabelka id [bigint], tytuł [char(255)], data [DATE]

24727 wpisów, indeksy id PRIMARY, tytul FULLTEXT

zapytanie SELECT * FROM tabelka WHERE MATCH(tytul) AGAINST ("+f*" IN BOOLEAN MODE) wykonywało się w szczycie...

32 sekundy

a tak średnio, nie licząc kilkunastosekundowych wyskoków, to poniżej 0.05- ale żeby aż taka była z chwilową wydajnością w home? Toż ta tabelka ma raptem pare mega! A przytyki bazy były wyraźne kilkanaście razy w ciągu dnia, na kilka-kilkanaście minut.

No chyba że popełniam jakiś szkolny błąd w tych testach, to jak ktoś go widzi proszę o naprostowanie.

Zdziwiony jestem bardzo ale chyba przestane polecać klientom home z tekstem "tam na pewno będzie dobrze"

[Ważka]

Zmien typ pola title z char(255) na varchar(255) - powinno troche pomoc.

[Mion]

Zmien typ pola title z char(255) na varchar(255) - powinno troche pomoc.

Pola typu char są szybciej przeszukiwane niż pola typu varchar. Wiec wprowadzasz w błąd!

@weecioo podaj wielkość przedmiotowej bazy danych.

/*** DALEJ ***/

Mam na home konto jeszcze jako testowe wiec zrobiłem mały test:

założyłem tabele taką jak Twoja 3 pola id | tytuł | data

pola wypełniłem w pętli w kolumnie tytuł zamieściłem tekst:

"Losowy ciąg liczb:19382074474454853c884b4 dalej As of MySQL 3.23.23, MySQL has support for full-text indexing and searching"

ciągi liczbowe w tych 25 984 rekordach są unikalne

Twoje zapytanie wykonuje się w:

SELECT * FROM test WHERE MATCH(tytul) AGAINST ("+f*" IN BOOLEAN MODE)

Pokaż rekordy 0 - 29 (25 984 wszystkich, Wykonanie zapytania trwało 0.0001 sekund(y))

Liczba rekordów : 25 984 wielkosc bazy 10,2 MB

w jednym z losowo wybranych rekordów zamieściłem ciąg test i wyszukiwanie:

SELECT * FROM test WHERE MATCH (tytul) AGAINST ('test');

Pokaż rekordy 0 - 0 (1 wszystkich, Wykonanie zapytania trwało 0.0006 sekund(y))

Tak to wyglada w moim, testowym przypadku

[Ważka]

Pola typu char są szybciej przeszukiwane niż pola typu varchar. Wiec wprowadzasz w błąd!

Panie madralo pola typu varchar sa szybciej przeszukiwane niz pola typu char. Wiec sam wprowadzasz w błąd!

Sam testowalem i wyniki wyszukiwania byly znaczaco szybsze, a nie slyszalem gdzies tam, ze podobno...

CHAR - Pole znakowe o stałej długości z zakresu od 1 do 255 bajtów. Po wstawieniu wartości puste miejsca pola CHAR są uzupełniane z prawej strony spacjami.

VARCHAR - Pole znakowe o zmiennej długości z zakresu od 1 do 255 bajtów. Zajmowany jest jedynie taki obszar pamięci, jakiego wymaga wartość wstawiona w to pole.

[Mion]

Panie madralo pola typu varchar sa szybciej przeszukiwane niz pola typu char. Wiec sam wprowadzasz w błąd!

* zdecydowanie bardziej wierze licznym autora książek o SQL niż twoim testom...

Pierwszy lepszy netowy artykuł na ten tamat pol .CHAR vs VARCHAR

Wiec pozostań przy swojej mylnej teori

* wiem jaka jest różnica, więc nie musisz się produkować

[Ważka]

Widac posiadasz za duzo teorii, a za malo praktyki.

Specjalnie dla Ciebie zrobilem przed chwila 2 testy na tabelach z ok. 80 000 i 130 000 rekordami i o dziwo znowu potwierdzily sie moje "mylne teorie".

A napisalem Ci co oznaczaja oba pula bo latwowiernie myslalem, ze zakumasz, ze jezeli cos zajmuje wiecej pamieci i wiecej nie potrzebnych znakow jest dluzej przeszukiwane niz cos co zajmuje tylko tyle miejsca ile na to potrzebuje.

Tytuly posiadaja zmienna dlugosc znakow, a nie zawsze taka sama.

Jezeli posiadaly by zawsze np. 15 znakow wtedy dobre by bylo pole CHAR, w tym wypadku lepsze jest VARCHAR. Koniec i kropka.

[Mion]

. Koniec i kropka.

... są ludzie którzy nadal wierzą, że ziemia jest płaska ...

Jednak wykorzystanie modelu II[CHAR] niesie za soba znaczne zwiekszenie szybkosci wyszukiwania danych. Kazdy rekord zajmuje zawsze tyle samo miejsca, latwiej jest wiec wyszukac szukany rekord (aby odnalesc poczatek rekordu w pliku danych, wystarczy przemnozyc nr rekordu przez jego dlugosc). W przypadku modelu I [VARCHAR] nie jest to juz takie proste, gdyz wczesniejsze rekordy zajmuja rozna ilosc miejsca.

[Ważka]

Chlopie przestan byc zgryzliwy.

Nie cytuj ksiazek i artykulow wyszukanych w googlu, ktore odnosza sie do innych przykladow. Chodzi o konkretny przyklad pola 'tytuly'.

Lepiej potwierdz swoja teorie FAKTAMI i DOWODAMI, ktorych niestety nie masz, a ja mam.

Ja Sprite, Ty pragnienie. Proste.

[Mion]

Lepiej potwierdz swoja teorie FAKTAMI i DOWODAMI, ktorych niestety nie masz, a ja mam.Ja Sprite, Ty pragnienie. Proste.

Wiec dalej w temacie wydajnosci home:

kolejne testy tabele o polach: id | tytul | data

ilość rekordow 100 000

rekord w tabeli tytul dla obydwu tabel zawsze taki sam: "Losowy ciag liczb ciag testowy :14984069164454b7587ba6c dalej As of MySQL 3.23.23, MySQL has support for full-text indexing and searching"

dwie różne tabele:

tytyl CHAR 255 wielkosc tabeli: 49,4 MB

tytul VARCHAR 255 wielkosc tabeli: 37,3 MB

zapytanie: SELECT * FROM $nazwa_tabeli WHERE MATCH (tytul) AGAINST ('Losowy ciag liczb 14984069164454b7587ba6c');

Dla obydwu tabeli Wykonywano średnio: Wykonywano:0.000615

Wiec z tego testu wynika, że ani ja, ani moj adwersarz nie ma racji.

Ale Konkluzja jest taka, że home dobrze razdzi sobie z SQL

Ciekawe co na to autor postu.

[weecioo]

hmm no ja powiem tak- średnio to zapytania wykonują się duzo mniej, problem jest z chwilową wydajnością - jak pisałem- kilka przytyków trwających po kilka-kilkanaśnie minut, wystarczająco żeby klient to zauważył. Tak że testy w postaci kilkukrotnego puszczenia tego samego zapytania nie starczą... poza tym, jesli ciąg jest taki sam, to fultekstowe wyszukiwanie nie dzala tak jak gdy są różne ciągi... więc testy z takim samym ciągiem to nie to samo

A jeśli chodzi o problem char/varchar, to https://dev.mysql.com/doc/refman/4.1/en/tips.html : "For MyISAM tables that change frequently, you should try to avoid all variable-length columns"

No i wreszcie, problem nie jest w zajmowaniu pamięci tylko jak długość pola jest stała to Mysqł może sobie policzyć gdzie będzie w pliku początek następnego rekordu bez czytania poprzedniego - o to w tym chodzi a nie o brak zasobów, przynajmniej nie w przypadku tabelek po kilkanaście mega... to też gdzieś w manie do mysqla jest tylko teraz nie mam czasu znaleźć gdzie )

[Mion]

Tak że testy w postaci kilkukrotnego puszczenia tego samego zapytania nie starczą... poza tym, jesli ciąg jest taki sam, to fultekstowe wyszukiwanie nie dzala tak jak gdy są różne ciągi... więc testy z takim samym ciągiem to nie to samo

Nie ma to aż takiego znaczenia.

Testowane tabele miały po 100 000 [sto tysięcy rektorów] sprawdzalem dziesiątki razy i czas zapytania nigdy nie przekraczał 0,5 sekundy nie było żadnego przytyku i nie ma większego znaczenia czy będą to rekordy o tej samej długości czy zmienne ponieważ dla kolumny char i tak mają zawsze tą samą długość.

Nie wiem skąd te twoje przytyki "przytyków trwających po kilka-kilkanaśnie minut" dla tabeli z 24 000 rekordów może są to różne maszyny ale nie taka różnica... Jakoś ten twój problem mgliście widzę

[infobank]

a może to zamiast bazy - wina - łącza?

[weecioo]

Nie wiem skąd te twoje przytyki "przytyków trwających po kilka-kilkanaśnie minut" dla tabeli z 24 000 rekordów może są to różne maszyny ale nie taka różnica... Jakoś ten twój problem mgliście widzę

no gdyby nie to, ze to na tej nieszczesnej tabelce z 3 kolumnami to tez bym mgliscie to widzial... ale fakt jest faktem- tabelka jak wyżej- czas wykonania jak wyżej- kilka razy w ciągu dnia. Notorycznie Więc albo robię coś megagłupiego od czego tak się dzieje, albo obcięli mi zasoby, albo się nie wyrabiają. A że to różne maszyny to pewne, przecież nawet jak był sławetny pad po wdrożeniu mod_rewrite to zdaje sie nie wszystkim padło

a może to zamiast bazy - wina - łącza?

to na 100% nie bo tam jest włączony output buffering a czas mierzę sobie sam. Chyba ze phpMyAdmin ma ob wyłączony to on moze fałszować pomiary ale to juz nie wiem jak jest.

[sorrow]

Zauważył ktoś iż home korzysta z Innodb co i tak wpływa dobrze na szybkości wyszukiwania w porównaniu z innymi hostingami

[Mion]

Wykonywałem kolejny test tym razem na własnym serwerze testowym na którym na którym w tym czasie nic innego nie działało wiec środowisko testowe było miarodajne.

dwie tabele po 70 000

zapytanie:

SELECT * FROM $nazwa_tabeli WHERE MATCH (tytul) AGAINST ('to jest ciag testowy do wyszukania');

Wyniki:

dla tabeli z tytul(char255) średnia: 0.33846 sek

dla tabeli z tytul(varchar255) średnia: 0.37961 sek

Wnioski: tabele oparte na polach char choć są większe, jednak są wydajniejsze

Ja Sprite, Ty pragnienie. Proste.