SQL sprzężenia wewnętrznego vs podzapytaniu

Question

Pracuję na następujące pytania:

Query 1: SELECT * From TabA INNER JOIN TabB on TabA.Id=TabB.Id 
Query 2: SELECT * From TabA WHERE Id in (SELECT Id FROM TabB) 
Query 3: SELECT TabA.* From TabA INNER JOIN TabB on TabA.Id=TabB.Id 

I zbadanie tych zapytań SQL Server Profiler i znaleźć kilka interesujących faktów.

• Zapytanie 1 odbywa 2.312 sekund
• Zapytanie 2 trwa 0,811 sekund
• Zapytanie 3 ma 0,944 sekund

taba 48716 wierszy

Tabb 62719 wierszy

Zasadniczo pytam, dlaczego Query 1 zajmuje dużo czasu, a nie zapytania 3. Już wiem, że "sub-zapytanie" jest wolniejsze niż wewnętrzne sprzężenie, ale tutaj Query 2 jest najszybsze; czemu?

Answer 1

Gdybym musiał zgadywać, powiedziałbym, że to dlatego, że zapytanie 1 pobiera dane z obu tabel. Zapytania 2 i 3 (w tym samym czasie) pobierają tylko dane dla TabA.

Jeden sposób można sprawdzić to wykonując następujące czynności:

SET STATISTICS TIME ON 
SET STATISTICS IO ON 

Kiedy wpadłem

SELECT * FROM sys.objects 

widziałem następujące wyniki.

SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 104 ms. 

(242 row(s) affected) 
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'sysschobjs'. Scan count 1, logical reads 10, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'syssingleobjrefs'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'syspalnames'. Scan count 1, logical reads 2, physical reads 1, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 866 ms. 

Możesz rzucić okiem na # skanów, odczytów logicznych i fizycznych odczytów dla każdego zapytania. Fizyczne odczyty oczywiście trwają znacznie dłużej i reprezentują odczyt z dysku do pamięci podręcznej. Jeśli wszystkie twoje odczyty są logiczne, to twoja tabela jest całkowicie w pamięci podręcznej.

Byłbym skłonny się założyć, jeśli spojrzeć widać dużo bardziej logiczne czyta na Tabb na zapytania 1 niż na 2 i 3.

EDIT:

Tak z ciekawości zrobiłem niektóre testy i blogowane wyniki here.

Answer 2

Po prostu dlatego, że SQL nie musi wykonywać JOIN. Właśnie wykonuje dwa kwerendy i tylko jeden z nich ma klauzulę WHERE.

Muszę przyznać, że nie spodziewałem się TAK dużej różnicy.

Answer 3

Zapytanie 1:
To zapytanie powoduje zwrócenie wierszy ze wszystkich wierszy zarówno w TabA, jak i TabB, więc indeks zakrycia dla obu tabel wymaga uwzględnienia wszystkich wierszy z każdej tabeli. Aby zobaczyć dokładnie, co się dzieje, należy spojrzeć na plan zapytania.

Query 2 & Zapytanie 3:
Wracasz wszystkie wiersze z Taba i trzeba tylko indeks dla kolumny Identyfikator Tabb. Zgaduję, że różnica tutaj ma coś wspólnego ze statystyką tabeli, ale (po raz kolejny) musielibyśmy zobaczyć plan zapytań, aby dokładnie wiedzieć, co się dzieje.

Answer 4

Jeśli łączenie jest jednym z wielu, możliwe jest, że to, co wymaga czasu, to powtarzające się dane. Zamiast tego można sformatować zestaw powiązanych wierszy jako tablicę JSON. Sprawdź "Przypadku użycia 1" na https://blogs.msdn.microsoft.com/sqlserverstorageengine/2015/10/09/returning-child-rows-formatted-as-json-in-sql-server-queries/