Szybkość LIKE

0

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?

0

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?

0

Rozumiem :) Dzieki za odpowiedź.

0
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?

0

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,

0

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łę".

0
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,

0

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.

0

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'
0

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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0