czemu optymalizator nie używa indeksu Opcje

[tmk]

w tabeli prac mam: id_prac, nazwisko, id_zesp. Założyłem index na nazwisko(zwykły index ).
proszę o pomoc , ponieważ:
dla zapytania:

[SQL] pobierz, plaintext 
SELECT* 
FROM prac
 WHERE nazwisko LIKE 'kowal%'
[SQL] pobierz, plaintext 

jest wykorzystwany index(table access->by index rowid)
natomiast dla zapytań:

[SQL] pobierz, plaintext 
SELECT* 
FROM prac
 WHERE nazwisko LIKE '%kowal'
[SQL] pobierz, plaintext 

oraz

[SQL] pobierz, plaintext 
SELECT* 
FROM prac
 WHERE nazwisko LIKE 'kowal%' OR nazwisko LIKE 'olek%'
[SQL] pobierz, plaintext 

optymalizator nie używa indexu

z czego to wynika?

[SongoQ]

Index to posortowany zbior danych wiec jesli znasz pierwsza litere to algorytmem btree wyszukuje dopasowan i podobnie z kolejnymi literami. Dla LIKE '% tego nie moze uczynic wiec przeszukuje wszyskie wartosci. Jak takie cos przyspieszyc - niestety nie wiem

[tmk]

a jeśli chodzi o to OR ? masz może jakiś pomysł czemu nie korzysta z indeksu w tym przypadku?

z tego co zauważyłem, czasem OR zamienia na UNION ALL i wtedy już korzysta z indeksu..

[Synaps]

Optymalizator nie skorzysta z indeksu jeśli użyłeś OR z wykorzystaniem pól zawartych w tych indeksie, to jedna z właściowości CBO. Like'i ktorych uzywasz w zapytaniu takze nie pomagaja w poprawnym wykorzystaniu indeksu. Sprobuj dodac wskazowke do optymalizatora /*+ FIRST_ROWS INDEX(nazwa_tabeli nazwa_indeksu) */, sprawdz ja k sie zachowa i postnij tutaj explain plan.

[tmk]

Synaps: stwierdzenie faktu że nie dziala korzystanie z indeksu nic nie wyjaśnia. Widzę, ze tak jest, bo mam przed sobą explain plan. Ja zadałem pytanie dlaczego

Dla LIKE '%kowal tego nie moze uczynic wiec przeszukuje wszyskie wartosciJak takie cos przyspieszyc - niestety nie wiem

A może spróbować wymusić odwrócony INDEX? jakoś może:

[SQL] pobierz, plaintext 
SELECT/*+ INDEX (prac nazwisko_idx) REVERSE*/* 
FROM prac
 WHERE nazwisko LIKE '%kowal'
[SQL] pobierz, plaintext 

wkońcu po coś są te reverese-indexy

jeszcze nie miałem chwili, żeby to sprawdzić, dam znać jaki efekt po południu

Ten post edytował tmk 4.03.2006, 10:09:42

[Synaps]

W przypadku zapytania z OR podejzewam ze indeks nie jest wykorzystany dlatego iz koszt full scana tabeli jest mniejszy niz dwa skany indeksu nawet po rowid. Zapewne też działa tutaj RBO a nie CBO, jak dodasz wskazówke /*+FIRST_ROWS*/ prawdopodobnie opt skorzysta z indeksu, ale kosz wykonania będzie wiekszy niż bez niego.( zakładam też że masz wygenerowane statystki dla tabeli oraz indeksu) Oczywiście to tylko przypuszczenia bo nie wkleiłeś żadnego explain planu.



btw: co do mojego stwierdzenia dot. OR w poscie powyżej to moja pomyłka, wydawało mi się że jako drugi warunek daleś '%wartosc' co nie pozwala korzystac z indeksu ze wzgledu na niemozliwosc okreslenia przedzialu poszukiwania ( dokladnie poczatku ).

Ten post edytował Synaps 6.03.2006, 15:16:31

[tmk]

znalazłęm, że w Oracle 10g jest mechanizm Oracle Text przeznaczony właśnie do wyszukiwania ciągów (rozwiązanie '%coś%')