Wydajność JOIN

Wydajność złączeń zależy od dostępnych indeksów i wybranego przez optymalizator algorytmu, np. Hash czy Merge.

Od czego zależy koszt wykonania złączenia

JOIN łączy wiersze z dwóch lub większej liczby tabel na podstawie warunku określonego w klauzuli ON albo, w szczególnych przypadkach, w USING. Wydajność takiej operacji zależy przede wszystkim od liczby przetwarzanych wierszy, rozkładu wartości w kolumnach łączenia, dostępnych indeksów oraz sposobu wykonania wybranego przez optymalizator zapytań. Sam zapis JOIN nie określa jeszcze, czy silnik odczyta całe tabele, wykorzysta indeks, utworzy strukturę pomocniczą w pamięci, czy posortuje dane.

Znaczenie ma także rodzaj złączenia. INNER JOIN zwraca tylko wiersze mające dopasowanie po obu stronach. LEFT JOIN zachowuje wszystkie wiersze z tabeli po lewej stronie, nawet gdy po prawej nie istnieje odpowiadający rekord. Złączenia zewnętrzne mogą więc zwrócić więcej danych niż oczekiwano, zwłaszcza gdy warunek nie jest jednoznaczny. Jeżeli jedna wartość w tabeli nadrzędnej pasuje do wielu wierszy tabeli podrzędnej, wynik zawiera osobny wiersz dla każdej pary, a jego rozmiar może szybko wzrosnąć.

Indeksy i selektywność kolumn łączenia

Indeks na kolumnie używanej w warunku złączenia może ograniczyć liczbę odczytywanych rekordów, ale nie gwarantuje automatycznie szybszego wykonania. Optymalizator ocenia koszt różnych planów i może uznać, że skan całej tabeli będzie tańszy, jeżeli zapytanie ma zwrócić dużą część danych. Indeks jest szczególnie przydatny wtedy, gdy warunek jest selektywny, czyli odrzuca znaczną większość wierszy. Kolumna zawierająca niewiele różnych wartości, na przykład pole logiczne, zwykle daje mniejszą korzyść przy samodzielnym indeksowaniu.

Ważna jest zgodność typów danych po obu stronach warunku. Łączenie kolumn o różnych typach może wymusić niejawną konwersję, a ta może utrudnić użycie indeksu albo zwiększyć koszt obliczeń. Podobny problem występuje, gdy kolumna jest opakowana funkcją, wyrażeniem lub operacją rzutowania, której silnik nie potrafi obsłużyć za pomocą istniejącego indeksu. Przy dużych tabelach warto również sprawdzić, czy statystyki opisujące rozkład wartości są aktualne, ponieważ optymalizator wykorzystuje je do oszacowania liczby dopasowań.

Hash join, merge join i nested loop

Jednym z możliwych algorytmów jest nested loop join, czyli złączenie pętli zagnieżdżonych. Silnik wybiera tabelę zewnętrzną, a dla każdego jej wiersza wyszukuje dopasowanie w tabeli wewnętrznej. Taki plan może być korzystny, gdy pierwsza tabela po filtrach jest mała, a po stronie wewnętrznej istnieje skuteczny indeks. Przy dużej liczbie wierszy i braku odpowiedniego dostępu do danych liczba powtarzanych odczytów może jednak stać się bardzo wysoka.

Hash join buduje tablicę mieszającą dla jednego ze zbiorów, a następnie wyszukuje w niej klucze z drugiego zbioru. Ten algorytm często pasuje do większych, nieposortowanych danych i złączeń opartych na równości, takich jak a.id = b.id. Jeżeli struktura nie mieści się w dostępnej pamięci, silnik może użyć plików tymczasowych, co zwiększa koszt operacji. Merge join przetwarza dwa wejścia uporządkowane według klucza złączenia. Gdy dane są już posortowane albo istnieją indeksy zapewniające właściwą kolejność, metoda ta może ograniczyć dodatkową pracę. Jeżeli sortowanie dopiero trzeba wykonać, koszt przygotowania wejścia może być znaczący.

Odczyt planu wykonania i diagnostyka

Ocena wydajności JOIN powinna opierać się na planie wykonania, a nie wyłącznie na czasie pojedynczego uruchomienia. Plan pokazuje między innymi wybrany algorytm złączenia, sposób dostępu do tabel, przewidywaną i rzeczywistą liczbę wierszy, operacje sortowania oraz wykorzystanie pamięci. Duża różnica między estymowaną a rzeczywistą liczbą rekordów wskazuje na problem z informacjami używanymi przez optymalizator, z rozkładem danych albo z parametrami zapytania.

Przy analizie należy sprawdzić, czy filtr jest wykonywany przed złączeniem, czy dopiero po utworzeniu większego zbioru pośredniego. Trzeba również zweryfikować warunek ON, ponieważ brak części klucza lub przypadkowe połączenie wielu wierszy może powodować iloczyn kombinacji i pozornie „wolny” JOIN. Pomocne jest porównanie planu dla małego i dużego zakresu danych, obserwacja liczby odczytów oraz sprawdzenie, czy zapytanie zwraca tylko potrzebne kolumny. W praktyce poprawa wydajności może wymagać zmiany indeksu, ograniczenia zbioru wejściowego, korekty warunku złączenia albo aktualizacji statystyk, a nie samej zamiany jednego rodzaju JOIN na inny.