Szybkość LIKE

Czykolumna LIKE 'String' jest dużo wolniejsze od porównywania liczb? Bo wydaje mi się, że wolniejsze to na pewno jest. Czy na siłe stosować wszedzie w bazie ID w postaci liczby, które wskazuje na jakiś napis, czy wstawiać od razu ten napis?

LIKE jest wolne. Nie ma co do tego watpliwosci. Nalozenie indeksu pomoze, ale nie zda sie na wiele jezeli rekordow bedzie b. duzo.

Co do Twojego pytania - stosuj osobna tabele z ID. Nazywa sie to procesem normalizacji.

Przykladowo masz w tabeli wstawiac miejsce zamieszkania uzytkownika. Tworzysz kolumne user_location:

user_location SMALLINT(6)

Nastenpie kolejna tabele - np. location:

location_id SMALLINT(6)
location_text VARCHAR(100)

W user_location przechowujesz tylko ID z tabeli location (klucz obcy). Rozumiesz?

Rozumiem :) Dzieki za odpowiedź.

Adam Boduch napisał(a)

Co do Twojego pytania - stosuj osobna tabele z ID. Nazywa sie to procesem normalizacji.

No dobrze, to ja mam takie pytanie z ciekawości.
Jeśli chcemy wyszukać użytkowników mieszkających gdzieś tam, to czy wykonanie podzapytania przeszukującego tabelę useres_location, które przez LIKE wyszukuje miejsca zamieszkania, a potem zapytania w tabeli users dla kluczy obcych zwróconych przez tamto podzapytanie będzie szybsze?

Może być szybsze, ale nie musi. Rozważ sytuacje:

• masz milion userów i 100 miejsc zamieszkania
• masz milion userów i pół miliona miejsc zamieszkania

pzdr,

A jeśli mam tysiąc userów i tysiąc miejsc zamieszkania? Bo jak zrozumiałem o taką sytuację pyta autor, skoro używa słów "na siłę".

somekind napisał(a)

A jeśli mam tysiąc userów i tysiąc miejsc zamieszkania? Bo jak zrozumiałem o taką sytuację pyta autor, skoro używa słów "na siłę".

W takiej sytuacji nie ma sensu rozbijać na 2 tabelki. Jeśli ograniczenie jest jest typu LIKE %costam%, to lepiej zrobić tablescana na tabeli i wyszukiwać %costam% niż robić tablescana na tabelsce (id, miejsce zamieszkania), a później dodatkowo złączenie z tabelką użytkowników.

Rozbijanie na 2 tabele ma sens wtedy, gdy liczba użytkowników >> liczba miejsc zamieszkania.

Nie wiem jak ma się sprawa z indeksowaniem pełnotekstowym, ale z tego co pamiętam to np. w Oracle stosuje się do tego inne klauzule niż LIKE (bodajże CONTAINS).

pzdr,

Dorzucę od siebie tylko tyle że niektóre enginy (np FB) nie skorzystają z indeksu gdy napiszesz LIKE '%xxx%' ale skorzystają gdy użyjesz STARTING WITH (czy coś takiego). Oczywiście wtedy % na początku odpada.

To i ja dorzuce swoje 3 grosze:

1. Like jest wolniejsze od =
2. Stosuj zawsze ID
3. Porownywanie stringow czy tez liczb mozemy uznac za tak samo szybkie po nastepujacymi warunkami:
   a) masz zalozony na kolumnie po ktorej szukasz index
   b) porownujesz kolumny poprzez = czyli. where kolumna = 'string'

No to ja tez cos od siebie:

w porownaniach like uzywaj zawsze opertorow SARG like 'xxx%' zamiast like '%xxx%'

przy porownywaniu stringow '=' uzywaj CHARINDEX(string1) = charindex(string2) or string1 = string2.