Wydajność podzapytań

Wydajność podzapytań bywa niższa niż złączeń — optymalizator nie zawsze przekształca je w równoważną, szybszą formę.

Jak podzapytanie wpływa na plan wykonania

Wydajność podzapytań zależy przede wszystkim od tego, w jaki sposób silnik bazy danych przekształci zapytanie na plan wykonania. Podzapytanie jest zapytaniem umieszczonym wewnątrz innego zapytania, na przykład w klauzuli WHERE, FROM albo SELECT. Sam fakt użycia podzapytania nie oznacza jeszcze problemu z szybkością. Znaczenie ma jego rodzaj, liczba zwracanych wierszy, dostępne indeksy, rozmiar tabel oraz sposób połączenia podzapytania z zapytaniem zewnętrznym.

Optymalizator może rozpoznać, że podzapytanie jest równoważne złączeniu albo innej postaci operacji relacyjnej, a następnie wybrać korzystniejszy plan. Nie każda konstrukcja daje się jednak bezpiecznie przepisać. Szczególne znaczenie ma zależność podzapytania od bieżącego wiersza zapytania zewnętrznego. Podzapytanie niezależne może zostać wykonane raz lub przekształcone do postaci tymczasowego zbioru wyników, natomiast podzapytanie skorelowane może wymagać wielokrotnego sprawdzania warunku.

Podzapytania skalarne, niezależne i skorelowane

Podzapytanie skalarne powinno zwracać pojedynczą wartość, na przykład maksymalną cenę albo datę ostatniej operacji. Jeżeli obliczenie jest niezależne od wierszy zapytania zewnętrznego, silnik może wykonać je tylko raz i wykorzystać wynik w dalszej części planu. Koszt takiej konstrukcji jest wtedy często niewielki, chociaż nadal trzeba uwzględnić skanowanie tabeli, filtrowanie oraz sortowanie wykonywane wewnątrz podzapytania.

Podzapytanie skorelowane odwołuje się do kolumn zapytania zewnętrznego. Logicznie może być oceniane osobno dla każdego wiersza, który przechodzi przez wcześniejsze etapy planu. Przy dużej tabeli zewnętrznej taki mechanizm może prowadzić do wielu powtórzeń tego samego wyszukiwania. Indeks na kolumnie używanej w warunku korelacji może ograniczyć koszt pojedynczego wyszukania, ale nie zawsze usuwa koszt powtarzania operacji. W innych przypadkach korzystniejsze okazuje się złączenie albo wcześniejsze pogrupowanie danych.

Podzapytania używane z operatorami EXISTS i NOT EXISTS mają inną charakterystykę niż podzapytania zwracające pełną listę wartości. Ich celem jest ustalenie, czy istnieje co najmniej jeden pasujący wiersz. Silnik może zakończyć sprawdzanie po znalezieniu pierwszego dopasowania, dlatego dobrze dobrany warunek i indeks mogą znacząco zmienić koszt wykonania. Przy analizie nie należy jednak zakładać takiego zachowania bez sprawdzenia rzeczywistego planu.

Indeksy, selektywność i liczba przetwarzanych wierszy

Na wydajność podzapytania wpływa selektywność warunków, czyli zdolność filtra do ograniczania liczby pasujących wierszy. Warunek oparty na kolumnie, która ma wiele różnych wartości, może szybciej zawęzić zbiór niż warunek dotyczący kolumny, w której większość rekordów ma tę samą wartość. Indeks może przyspieszyć odczyt, lecz jego użyteczność zależy od konkretnego predykatu, kolejności kolumn w indeksie oraz liczby rekordów spełniających warunek.

Problemem bywa również sytuacja, w której podzapytanie zwraca znacznie więcej danych, niż potrzebuje zapytanie zewnętrzne. Dotyczy to między innymi użycia IN z dużym zbiorem wynikowym, niepotrzebnego sortowania albo pobierania kolumn, które nie uczestniczą w dalszym filtrowaniu. Ograniczenie zakresu danych możliwie wcześnie może zmniejszyć liczbę odczytów i ilość pracy wykonywanej przez kolejne operatory planu.

Różnica między podzapytaniem a złączeniem nie sprowadza się do samej długości kodu. Dwie logicznie równoważne konstrukcje mogą otrzymać ten sam plan wykonania, ale mogą też zostać zrealizowane zupełnie inaczej. Zmiana składni bez sprawdzenia planu nie jest wiarygodną optymalizacją. Trzeba zweryfikować między innymi liczbę odczytanych wierszy, sposób użycia indeksów, kolejność operacji oraz to, czy podzapytanie jest wykonywane wielokrotnie.

Jak rozpoznawać koszt podzapytania w praktyce

Ocena wydajności powinna zaczynać się od odtworzenia rzeczywistego problemu: konkretnego zapytania, parametrów, wielkości tabel i aktualnych danych. Ten sam kod może działać poprawnie na małej bazie testowej, a po wzroście liczby rekordów powodować długie oczekiwanie. Należy także rozróżnić czas oczekiwania na wykonanie zapytania od czasu pobierania wyników przez aplikację, ponieważ opóźnienie może powstawać poza samym silnikiem bazy danych.

Przydatne jest porównanie kilku równoważnych wariantów: podzapytania skorelowanego, złączenia oraz konstrukcji wykorzystującej EXISTS, jeżeli logika wymaga jedynie sprawdzenia obecności rekordu. Każdy wariant powinien zwracać ten sam wynik, także dla pustych tabel, wartości NULL, duplikatów i przypadków brzegowych. Szczególnej uwagi wymaga logika trójwartościowa SQL, ponieważ NULL może powodować inny rezultat niż zwykła wartość i wykluczyć pozornie równoważne przepisanie warunku.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC, a w przypadku problemów z aplikacją można sprawdzić również lokalne objawy przeciążenia, takie jak długie oczekiwanie programu, wysokie użycie procesora lub pamięci oraz powtarzające się zawieszanie interfejsu. Sama obserwacja komputera nie potwierdza jeszcze, że przyczyną jest podzapytanie. Wiarygodna diagnoza wymaga powiązania objawu z konkretnym zapytaniem, planem wykonania i warunkami występującymi w bazie danych.