ABSOLUTNIE. Hash match byłby ogromną poprawą. Tworzenie skrótu w mniejszej tabeli 19 223 wierszy, a następnie sondowanie jej za pomocą większej tabeli 65 991 wierszy jest znacznie mniejszą operacją niż zagnieżdżona pętla wymagająca porównania 1 268 544 993 wierszy.
Jedynym powodem, dla którego serwer wybrałby zagnieżdżone pętle, jest to, że źle oszacował liczbę zaangażowanych wierszy. Czy Twoje tabele zawierają statystyki, a jeśli tak, to czy są one regularnie aktualizowane? Statystyki umożliwiają serwerowi wybór dobrych planów wykonania.
Jeśli prawidłowo zajęłeś się statystykami i nadal masz problem, możesz zmusić go do użycia połączenia HASH w następujący sposób:
SELECT *
FROM
TableA A -- The smaller table
LEFT HASH JOIN TableB B -- the larger table
Pamiętaj, że gdy to zrobisz, wymusi to również kolejność dołączania. Oznacza to, że musisz poprawnie ułożyć wszystkie stoły, aby ich kolejność łączenia miała sens. Ogólnie rzecz biorąc, należy sprawdzić plan wykonania, który serwer już posiada, i zmienić kolejność tabel w zapytaniu, aby była zgodna. Jeśli nie wiesz, jak to zrobić, podstawa jest taka, że każde „lewe” wejście jest pierwsze, a w graficznych planach wykonania lewe wejście jest dolne jeden. Złożone sprzężenie obejmujące wiele tabel może wymagać grupowania sprzężeń razem w nawiasach lub użycia RIGHT JOIN aby plan wykonania był optymalny (zamień lewe i prawe dane wejściowe, ale wprowadź tabelę we właściwym miejscu w kolejności łączenia).
Generalnie najlepiej jest unikać używania wskazówek dotyczących łączenia i wymuszania kolejności łączenia, więc najpierw zrób wszystko, co możesz! Możesz zajrzeć do indeksów w tabelach, fragmentacji, zmniejszenia rozmiarów kolumn (takich jak użycie varchar zamiast nvarchar gdzie Unicode nie jest wymagany) lub dzielenie zapytania na części (najpierw wstaw do tabeli tymczasowej, a następnie dołącz do niej).
