(zgodnie z zaleceniami umieszczam część mojego komentarza w odpowiedzi, ponieważ rozwiązało to problem)
Przekształć wyrażenia EXISTS na wyrażenia IN.
W tym przypadku działa to lepiej, ponieważ zapytanie będzie teraz efektywnie oceniane „od środka”, zaczynając od zapytania, które zawiera najbardziej ograniczający czynnik:wyszukiwanie pełnotekstowe. Zapytanie to zwróci mały zestaw wierszy, które można wyszukać bezpośrednio względem klucza podstawowego zapytania zewnętrznego (WHERE x in (SELECT X...)) w przeciwieństwie do wywoływania zapytania „wewnętrznego” raz na wartość zewnętrzne zapytanie (lub dla wszystkich wartości w oryginalnym przypadku, jeśli dobrze czytam). Metoda EXISTS w tym przypadku daje w wyniku zagnieżdżone pętle (jedna ocena jednego zapytania dla każdej wartości w innej) w porównaniu z metodą IN przy użyciu złączeń mieszających (znacznie wydajniejsza metoda wykonywania w wielu, jeśli nie w większości przypadków).
Zwróć uwagę, że w przypadku metody EXISTS istnieją cztery zagnieżdżone pętle, które są wykonywane, z których każda działa co najmniej 3000 razy. Ten koszt się sumuje. Chociaż nie jest to bezpośrednie porównanie, możesz traktować pętle zagnieżdżone tak, jak pętle FOR w kodzie aplikacji:za każdym razem, gdy wywołujesz pętlę wewnętrzną, twoje oszacowanie dużego O rośnie o rząd wielkości:O(n) do O(n^ 2) do O(n^3) itd.
Hash Join jest bardziej podobny do mapy, w której dwie tablice są przeszukiwane w tym samym czasie i na obu wykonywana jest operacja. Jest to z grubsza liniowe (O(n)). Pomyśl o tym, że są one zagnieżdżone jako addytywne, aby przejść od O(n) do O(2n) do O(3n) itd.
Tak, tak, wiem, że to nie to samo, ale chodzi o to, że posiadanie wielu zagnieżdżonych pętli zwykle wskazuje na powolny plan zapytania, a porównanie dwóch stylów big-O ułatwia rozpoznanie, jak sądzę.
Zagnieżdżone pętle i ISTNIEJE same w sobie nie są złe, ale w większości przypadków istnieje podstawowy warunek filtrowania, który ostatecznie wpływa na wszystko (na przykład wyszukiwanie pełnotekstowe w pytaniu), wyrażenie IN (lub, w niektóre przypadkach, prawidłowe JOIN) daje znacznie bardziej wydajny plan.
