LIKE i index u mysql
Znam za pricu da mysql ne koristi index ako mu se zada upit sa LIKE '%nesto%', medjutim u ovom clanku Peter Zaitsev navodi upravo taj primer i kaze da taj upit koristi index.
Proverio sam na test bazi u lokalu, sa istom tabelom koju on koristi i explain kaze da ne koristi index?! Da je neko drugi u pitanju mislio bih da lupeta ili se zeznuo nesto, ali Peter je faca i zna sta prica, tako da ce pre biti da ja nesto nisam dobro razumeo? Ili se zeznuo zaista? |
Upit
Kôd:
select c from t1 where c = “abc” order by c limit 1 Kôd:
select c from t1 where c like “abc%” order by c limit 1 Eh sad, ovaj zbunjujući: Kôd:
select c from t1 where c like “%abc%” order by c limit 1 - forward index scan |
Citat:
u Select deo ne ide kriterijum pretrage, vec mu se tu samo kaze koje dodatne kolone treba da pokupi kada utvrdi koji slogovi odgovaraju kriterijumu. jedino ako mislis da on radi table scan jer proceni da bi mu "index scan + dodatno citanje tih dodatnih kolona" oduzelo vise vremena nego table scan [koji odradi u jednom naletu] ? po toj logici bi se indexi retko kad koristili, jer uglavnom svi upiti fetch-uju i ta dodatna polja. |
Ako je kolona po kojoj se radi like jedina u indeksu, onda je očekivano pretraživanje samo preko indeksa:
* prolazak kroz indeks je brzi (indeks fizički manje zauzima blokova na disku) * kako lociram slog kroz indeks koji zadovoljava upit, imam direktan pointer i na odgovarajući slog u bazi (za izvlačenje ostalih polja iz SELECT dela) |
@Peca: Teoretski (pošto zaista ne znam kako konkretno radi MySQL), to da li je bolje da se radi index scan ili table scan, zavisi od toga koliko tabela ima kolona, koje od njih izvlačiš za select, ali i od procenta redova koje upit treba da vrati (npr. za velike slogove a mali procenat onih koji odgovaraju kriterijumu, svakako je bolje da se radi index scan bez obzira na to šta stoji u SELECT), tako da je do query planera da odluči da li je bolje da gleda indeks ili tabelu.
|
a kako se radi scan kad je u pitanju binarno stablo? Samo prodje kroz sve cvorove redom?
|
^ Nisam siguran da razumem pitanje, binarna stabla se uopšte ne koriste kao indeksi kod baza..
|
@peca Loše sam napisao, zavisi od konkretnog slučaja, trebalo je da napišem: može da se desi da uradi table scan. Kao što je jablan već rekao, zavisi od konkretnog slučaja šta će da odluči engine.
Sve ovo pričam na osnovu iskustva sa ms sql... Edit: Ispravio/dopunio bih prvi odgovor, ali ne mogu da editujem poruku, u svakom slučaju hvala na ispravci. |
@jablan: vidis, vidis... ziveo sam u iluziji da je btree i binary tree isto...
|
Sad naleteh na ovu raspravu (posto kolega i ja razmatramo koriscenje indexa u slucaju suffix pretrage -> like '%something'). Imho iako je u pitanju fenomenalan blog, u pitanju je clanak iz 2006 godine (poprilicno mator) a obzirom na dinamiku razvoja MySQL-a ja se radije drzim manuala. Uporedite samo razlike u textu za verzije 5.5 i 5.1 i bice vam jasno o cemu pricam :)
http://dev.mysql.com/doc/refman/5.5/...l-indexes.html http://dev.mysql.com/doc/refman/5.1/...l-indexes.html |
^ Bez obzira na podršku u konkretnoj verziji MySQL-a, za sufiksnu pretragu uvek možeš da zapišeš obrnut string pa da koristiš klasičnu prefiksnu pretragu, a pretpostavljam da može nešto da se nabudži i indeksiranjem po transformisanom polju (barem u Postgresu takve stvari su uobičajene), tipa:
Kôd:
CREATE INDEX i_tabela ON tabela(REVERT(string_field)); |
^Yep, taj trik smo bas nedavno primenili (obrnuli originalan string kao i search i tako dobili suffix search koji koristi indexe).
|
jel moze da se nesto iskombinuje, pa da se sa ta 2 polja dobije i '%X%' koji radi?
|
^ Heh, ne iz prostog razloga što %X% nije isto što i (%X OR X%) :)
Jedino što možeš je da za svaki string dodaš u bazu i sve njegove podstringove, u fazonu one praistorijske reklame "jugodrvo ugodrvo godrvo" pa onda koristiš X%. LOL http://vukajlija.com/jugodrvo/67366 |
Vreme je GMT +2. Trenutno vreme je 09:12. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.