Dlaczego podzapytanie i dołączanie są tak powolne?

Question

Muszę wybrać wiersze z tabeli BUNDLES, które mają jedną z kilku wartości SAP_STATE_ID. Wartości te zależą od tego, czy dany status SAP ma zostać wyeksportowany, czy nie.

Ta kwerenda działa bardzo szybko (istnieje indeks na polu SAP_STATE_ID) -

SELECT b.* FROM BUNDLES b WHERE b.SAP_STATE_ID IN (2,3,5,6) 

Ale ... Chciałbym listę identyfikatorów pobierać dynamicznie, tak:

SELECT b.* FROM BUNDLES b 
WHERE b.SAP_STATE_ID IN 
(SELECT s.SAP_STATE_ID FROM SAP_STATES s WHERE s.EXPORT_TO_SAP = 1) 

I ouch, to zapytanie nagle zajmuje zbyt dużo czasu. Spodziewam się, że najpierw serwer SQL uruchomi podzapytanie (nie zależy to od niczego z głównej kwerendy), a następnie uruchomi całą sprawę tak, jak w moim pierwszym przykładzie. Próbowałem przepisać go, aby użyć połączeń zamiast podzapytania:

SELECT b.* FROM BUNDLES b 
JOIN SAP_STATES s ON (s.SAP_STATE_ID = b.SAP_STATE_ID) 
WHERE s.EXPORT_TO_SAP = 1 

, ale ma tę samą słabą wydajność. Wygląda na to, że uruchamia podzapytanie dla każdego wiersza tabeli BUNDLES lub coś podobnego. Nie mam umiejętności czytania planów wykonania, ale próbowałem. Mówi się, że 81% koszt jest przeznaczony na skanowanie Primary key index BUNDLES (nie mam pojęcia, dlaczego powinien to zrobić, jest pole BUNDLE_ID zdefiniowane jako PRIMARY KEY, ale w ogóle nie pojawia się w zapytaniu ...)

Czy ktoś ma wyjaśnienie, dlaczego serwer SQL jest tak "głupi"? Czy istnieje sposób na osiągnięcie tego, co chcę, przy dobrej wydajności, ale bez potrzeby podawania statycznej listy identyfikatorów SAP_STATE_ID?

scenariusz dla obu tabel i odpowiednich indeksów - Plan http://mab.to/xbYiI0wKj

wykonania dla wersji podzapytanie - http://mab.to/8Qh6gpdYZ

planu kwerend dla wersji ze sprzężeń - http://mab.to/YCqeGCUbr

(z jakiegoś powodu te dwa plany wygląda tak samo i oba sugerują utworzenie indeksu BUNDLES.SAP_STATE_ID, który już istnieje)

Answer 1

Jestem całkiem pewny statystyki są wyłączone na stołach.Jeśli chcesz, aby to działa w pośpiechu chciałbym napisać kwerendę jako:

SELECT b.* 
    FROM SAP_STATES s 
INNER LOOP JOIN BUNDLES b 
    ON s.SAP_STATE_ID = b.SAP_STATE_ID 
WHERE s.EXPORT_TO_SAP = 1 

zmusza to zagnieżdżone pętle przyłączenia nad SAP_STATES który filtruje na BUNDLES

Answer 2

Ponieważ z jakiegoś powodu problemy z przejściem na mab.to,

Proponuję zapewnić następujące

table  index 
sap_states (export_to_sap, sap_state_id) 
bundles  (sap_state_id) 

select 
     b.* 
    from 
     sap_states ss 
     join bundles b 
      on ss.sap_state_id = b.sap_state_id 
    where 
     ss.export_to_sap = 1 

Answer 3

Podczas korzystania z tabel (tymczasowe lub fizycznych), silnik SQL buduje statystyk przeciwko nim, a więc ma bardzo jasne wyobrażenie o liczbie wierszy w nim, a które jest najlepszym podejściem do wykonania dla niego. Z drugiej strony, obliczona tabela (sub zapytanie) nie ma statystyk przeciwko niemu.

Podczas gdy człowiek może wydawać się prosty, aby wydedukować liczbę wierszy w nim, "głupi" Silnik SQL nie jest tego świadomy. Teraz, przychodząc do zapytania, klauzula WHERE s.EXPORT_TO_SAP = 1 robi tu wielką różnicę. Indeks klastrowany jest posortowany i zbudowany na SAP_STATE_ID, ale aby dodatkowo sprawdzić klauzulę WHERE, nie ma opcji, ale przeskanować całą tabelę (w ostatecznym zbiorze danych)! Założę się, że gdyby zamiast indeksu klastrowanego, gdyby istniał indeks klastrowany bez klastrów w kolumnie SAP_STATE_ID, który obejmował pole EXPORT_TO_SAP, mógł to zrobić. Od skupionych skany indeksy są na ogół złe dla wydajności, chciałbym zaproponować Ci podjąć poniżej podejścia:

SELECT s.SAP_STATE_ID 
into #Sap_State 
FROM SAP_STATES s WHERE s.EXPORT_TO_SAP = 1 

SELECT b.* FROM BUNDLES b 
join #Sap_State a on a.sap_state_id = b.sap_state_id