SQL ogromna różnica wydajności przy użyciu SELECT TOP x, nawet gdy x jest znacznie wyższa niż wybrane wiersze

Question

Wybieram niektóre wiersze z funkcji wycenione w tabeli, ale znalazłem niewytłumaczalną ogromną różnicę wydajności poprzez umieszczenie SELECT TOP w zapytaniu.

SELECT col1, col2, col3 etc 
FROM  dbo.some_table_function 
WHERE col1 = @parameter 
--ORDER BY col1 

trwa do 5 lub 6 minut do zakończenia.

Jednakże

SELECT TOP 6000 col1, col2, col3 etc 
FROM  dbo.some_table_function 
WHERE col1 = @parameter 
--ORDER BY col1 

zakończona w około 4 lub 5 sekund.

Nie zdziwiłoby mnie to, gdyby zwrócony zestaw danych był ogromny, , ale konkretne zapytanie dotyczyło ~ 5000 wierszy z 200 000.

W obu przypadkach cała tabela jest przetwarzana, ponieważ SQL Server kontynuuje wyszukiwanie 6000 wierszy, do których nigdy nie dotrze. Skąd ta ogromna różnica? Czy ma to jakiś związek ze sposobem, w jaki SQL Server przydziela przestrzeń w oczekiwaniu na rozmiar zestawu wyników (TOP 6000, co daje mu niskie wymagania, które łatwiej jest przypisać w pamięci)? Czy ktoś jeszcze był świadkiem czegoś takiego?

Dzięki

Answer 1

Funkcje wycenione w tabeli mogą mieć nieliniowy czas wykonania.

Rozważmy odpowiednik funkcji dla tego zapytania:

SELECT (
     SELECT SUM(mi.value) 
     FROM mytable mi 
     WHERE mi.id <= mo.id 
     ) 
FROM mytable mo 
ORDER BY 
     mo.value 

To zapytanie (który oblicza biegu SUM) jest szybki na początku i powoli na koniec, ponieważ w każdym rzędzie od mo należy zsumować wszystkie poprzedzające wartości, które wymagają przewijania wierszy.

Czas do obliczenia SUM dla każdego wiersza wzrasta wraz ze wzrostem liczby wierszy.

Jeśli zrobisz mytable wystarczająco dużą (powiedzmy 100,000 wierszy, jak w twoim przykładzie) i uruchom to zapytanie, zobaczysz, że zajmuje to dużo czasu.

Jeśli jednak zastosujesz TOP 5000 do tego zapytania, zobaczysz, że kończy się znacznie szybciej niż 1/20 czasu potrzebnego na pełną tabelę.

Najprawdopodobniej coś podobnego dzieje się również w twoim przypadku.

Aby powiedzieć coś zdecydowanie, potrzebuję zobaczyć definicję funkcji.

Aktualizacja:

SQL Server może wypchnąć predykaty do funkcji.

Na przykład, po prostu stworzył ten TVF:

CREATE FUNCTION fn_test() 
RETURNS TABLE 
AS 
RETURN (
     SELECT * 
     FROM master 
     ); 

te pytania:

SELECT * 
FROM fn_test() 
WHERE name = @name 

SELECT TOP 1000 * 
FROM fn_test() 
WHERE name = @name 

dawać różne plany wykonania (pierwszy z nich używa klastrowego skanowanie, drugi wykorzystuje indeks szukać z TOP)

Answer 2

To niekoniecznie prawda, że ​​cały stół jest przetwarzany, jeśli col1 ma indeks.

Optymalizacja SQL określa, czy użyć indeksu. Być może twój "TOP" zmusza go do korzystania z indeksu.

Jeśli używasz MSSQL Query Analyzer (Nazwa ucieka mi), naciśnij Ctrl-K. Spowoduje to wyświetlenie planu wykonania zapytania zamiast jego wykonania. Przypuszczam, że pokazanie ikon wskazuje na użycie IO/CPU.

Założę się, że jeden używa wyszukiwania indeksu, a drugi nie.

Jeśli masz ogólne klienta: SET SHOWPLAN_ALL ON; GO wybierz ...; iść

zobaczyć http://msdn.microsoft.com/en-us/library/ms187735.aspx o szczegóły.

Answer 3

Być może używasz tutaj czegoś tak prostego jak buforowanie - być może (z jakiegokolwiek powodu) zapytanie "TOP" jest buforowane? Używając indeksu, którego nie ma drugi?

W każdym razie najlepszym sposobem na zaspokojenie swojej ciekawości jest zbadanie pełnego planu wykonania dla obu zapytań. Możesz to zrobić bezpośrednio w SQL Management Console i powie Ci dokładnie, jakie operacje są wykonywane i jak długo każdy z nich jest przewidywany.

Wszystkie implementacje SQL są dziwaczne na swój własny sposób - SQL Server nie jest wyjątkiem. Taki rodzaj "whaaaaa ?!" chwile są dość powszechne. ; ^)

Answer 4

Twój TOP ma ORDER BY, więc jest to po prostu taki sam jak SET ROWCOUNT 6000 pierwszy. ORDER BY wymagałby najpierw oceny wszystkich wierszy, a to zajmie dużo więcej czasu.

Jeśli dbo.some_table_function jest tabelą wbudowaną o wartości udf, to jest to po prostu makro, które jest rozszerzone, więc zwraca pierwsze 6000 wierszy, jak wspomniano w żadnej konkretnej kolejności.

Jeśli UDF jest wielo cenione, to jest to czarna skrzynka i zawsze będzie ciągnąć w pełnym zbiorze przed filtrowaniem. Nie sądzę, żeby tak się działo.

niezwiązanych bezpośrednio, ale another SO question on TVFs

Answer 5

myślę sugestia Quassnois' wydaje się bardzo prawdopodobne. Dodając TOP 6000, domyślnie dajesz optymalizatorowi wskazówkę, że zostanie zwrócony dość mały podzbiór 200 000 wierszy. Optymalizator następnie korzysta z wyszukiwania indeksu zamiast sklasyfikowanego skanowania indeksu lub tabeli.

Kolejne możliwe wyjaśnienie może buforować, jak sugeruje Jim Davis. Jest to dość łatwe do wykluczenia przez ponowne uruchomienie zapytań. Spróbuj najpierw uruchomić model z TOP 6000.

Answer 6

Miałem ten sam problem, proste zapytanie łączące pięć tabel zwracających 1000 wierszy zajęło dwie minuty. Kiedy dodałem do niego "TOP 10000", zakończyło się to w mniej niż sekundę. Okazało się, że indeks klastrowy w jednej z tablic był mocno rozdrobniony.

Po odbudowaniu indeksu zapytanie kończy się w mniej niż sekundę.