MSSQL nie bierze pod uwagę wszystkich filtrów

Cześć. Mam funkcję skalarną, która jest wykonywana podczas selectu. Przy 8000 rekordów z hakiem, trwa to około 40 sekund, więc zacząłem się przyglądać, jak to zoptymalizować. Nie znalazłem właściwie nic, więc spojrzałem na plan wykonania.

I oto okazało się coś ciekawego.
Moje zapytanie wygląda mniej więcej tak:

select ve.date as dat1, MIN(ve2.date) as dat2, ve.includeWT
from Events as ve
inner join Events as ve2 on ve.eID = ve2.eID and
	ve.Date<ve2.date
where ve.date>='2010-05-04 08:42:01' and ve.date<='2010-05-04 16:39:33' 
	and ve2.date>='2010-05-04 08:42:01' and ve2.date<='2010-05-04 16:39:33'		
	and ve.eID = 117 and ve2.eid = 117
group by ve.eID, ve.date, ve.includeWT

Nie ważne co robi. Chodzi o filtr.

W pierwszym kroku plan pokazał Index Seek i pod nim Clustered Index Seek na tabeli Events.
Ilość rekordów, jakie zwróciła ta operacja jest równa podanemu przeze mnie zakresowi dat. Tylko. Czyli nie wziął pod uwagę pola EID.

Następnym krokiem jest Nested Loops(Inner Join), a następnym Filter i dopiero tutaj bierze pod uwagę pole EID. Jeśli dołożę warunek z EID do warunku joina, to też to nic nie zmienia.

Czemu tak się dzieje i jak to zmienić, żeby w pierwszym kroku już były odpowiednio okrojone dane?

a może byś tak łaskawie indexy pokazał

select ... from
(select cos1, cos2, ... from Tab1 where warunki_okrajajaca_jak_sie_da_dane) as T1
inner join (select ... from X where warunki) on ...
where ...

czyli generalna zasada, to przed zlaczeniem ogranicz dane jak tylko mozesz
ale i tak wiele zalezy od optymalizatora, moze to nie zawsze pomaga, ale raczej nie zauwazylem zeby tez szkodzilo, zazwyczaj byl zysk lub bez poprawy, zalezy od query

massther napisał(a)

select ... from
(select cos1, cos2, ... from Tab1 where warunki_okrajajaca_jak_sie_da_dane) as T1
inner join (select ... from X where warunki) on ...
where ...

Twój pomysł wypróbowałem jeszcze przed napisanem posta i było tak samo. Indeksy mam założone na pole ID.

Dałóż datę do indeksu.

Marcin.Miga napisał(a)

Dałóż datę do indeksu.

Damn, przepraszam za przeoczenie. Indeksy są na ID i datę. Czyli pola ID i Date

Po dołożeniu indeksu na pole EID, mam tak:

Index Seek - po samej dacie
pod nim Index Seek - po polu EID.

Dlaczego nie ma tego i tego?

daj polecenie create tej tabelki ze wszystkimi indexami etc.
mozesz pominac jakies kolumny
i powiedz ile masz tam mniej wiecej danych
od ilosci danych zalezy tez zachowanie optymalizatora
np. jak jest malo danych czasem optymalizator nie sili sie na swirowanie z indexami, etc.

Rekordów mam trochę ponad 61 tysięcy w tej tabeli.

Anyway, popróbowałem trochę z tymi indeksami i okazało się, że:

• jeśli usunę wszystkie indeksy(zostawię tylko ten na ID) to jest tak, jak powinno być
• jeśli dam indeksy tylko na ID i EID, to też jest tak, jak powinno być.

Niestety to zapytanie to część większej całości. I okazuje się, że jeśli zrobię z indeksami, jak powyżej, to całość trwa nawet do 3 razy dłużej. Czyli indeksy muszę mieć na ID i date.

nie pamietam czy jak sie zalozy index na 2 pola, to automatycznie statystyki tez sie zakladaja, jesli nie to zaloz i powykonuj troche tych zapytan
mozesz tez hint uzyc i zmusic optymalizator do uzycia konkretnego indexu, ale to czasem dobrze daiala na jednym srodowisku (np. testowym) a pozniej na produkcji sa problemy

massther napisał(a)

daj polecenie create tej tabelki ze wszystkimi indexami etc.
mozesz pominac jakies kolumny

możesz wreszcie do kur*** nędzy dać tego jebanego DDLa do indeksów czy mamy dalej wróżyć z fusów???

Chcesz naszej pomocy to zacznij odpowiadać na pytania

Wklejenie pełnego planu zapytania też byłoby pomocne, zamiast opowiadania go własnymi słowami.

plan wykonania zapytania nie równy planowi wykonania zapytania... zależy kiedy query analyzer raczył opracować ów plan. Jeśli tuż po uruchomieniu, kiedy bufor/cache puste, to faktycznie plan wykonania może wyglądać na rzetelny, natomiast jeśli odpalimy powtórnie to samo zapytanie, kiedy sporo stron już siedzi w pamięci, to plan zapytania może wyglądać inaczej.