Wydajność przy użyciu DISTINCT COUNT

Question

Używam SQL Server 2012.

Mam kwerendy, że gdy rozłożony na to najbardziej podstawowa forma wygląda następująco:

SELECT COUNT(DISTINCT fullAddress) as quickCount 
FROM leads 
WHERE yearID >=12 AND yearID <=21 

W tabeli prowadzi liczy około 149 milionów płyt w to. Istnieje indeks klastrowany na identyfikatorze leadID i indeks klastrowany, który jest indeksowany na YearID i zawiera element include dla fullAddress.

To zapytanie trwa około 40 sekund. Zdaję sobie sprawę, że nie jest źle, ale w tej sytuacji nie jest to wystarczająco szybkie.

Spojrzałem na plan wykonania iz tego co mogę powiedzieć o 60% kosztu to LICZENIE DISTINCT.

Kiedy uruchomić tę samą kwerendę bez DISTINCT COUNT takiego:

SELECT COUNT(*) as quickCount 
FROM leads 
WHERE yearID >=12 AND yearID <=21 

To trwa tylko 1 sekundę, aby uruchomić.

Niestety, muszę uzyskać liczbę różnych pełnych adresów. Próbuję więc dowiedzieć się, czy jest coś, co mogę zrobić, aby przyspieszyć pierwsze zapytanie.

Oto zrzut ekranu z planu wykonania dla obu zapytań:

Oto link do tego, żeby go zobaczyć większe - http://www.sequenzia.com/execPlan.jpg

Z tego co mogę powiedzieć mój główny problem jest Distinct Sort (52%).

Każda pomoc lub opinia na ten temat będzie świetna.

Dzięki!

UPDATE

Wziąłem porady Thilo i zastosowano ten indeks:

CREATE INDEX IDX_X ON LEADS(FULLADDRESS, YEARID); 

I faktycznie utworzony 2 nowe tabele testowe z dokładnie tego samego 1 milion rekordów w każdym z nich. Zastosowałem ten sam oryginalny indeks do obu, a następnie powyższego indeksu do jednego. Teraz, kiedy porównuję 2 tabele w tym samym planie wykonania, ten z powyższym indeksem jest nieco lepszy od 48% do 52%. Oto nowy plan wykonania - http://www.sequenzia.com/execPlan2.jpg

To pomaga niektórym, ale naprawdę potrzebuję większej wydajności. Jakieś inne pomysły?

Answer 1

Jedną z rzeczy, której należy spróbować, jest pozbycie się sortowania poprzez posiadanie indeksu zamówionego pod numerem fullAddress (który obejmuje również kolumnę yearID, aby można było również spełnić klauzulę where).

CREATE INDEX IDX_X ON LEADS(FULLADDRESS, YEARID); 

ten sposób powinieneś dostać Fast Pełny skanowania indeksu (prawdopodobnie jeszcze wolniej niż indeks zakres skanowania masz dla non-odrębnego zliczania, ale mam nadzieję, że szybciej niż 40s sortowanie).

Ale dlaczego musi być tak szybko? To nie jest coś, co musisz robić cały czas, prawda?Jeśli jest to dla publicznej strony internetowej, możesz uciec z nieco przestarzałym wynikiem w pamięci podręcznej, jak sądzę.

Answer 2

Jeśli nie aktualizowania tej tabeli bardzo często można spojrzeć na tworzenie indeksowany widok z zapytaniem używasz http://msdn.microsoft.com/en-us/library/aa933148(v=sql.80).aspx