Dołącz zapytanie lub podkwerendę

Question

Czy programiści mają do czynienia z regułami, kiedy używać join zamiast podkwerendy lub czy są one takie same.

Answer 1

Zależy od RDBMS. Powinieneś porównać plany wykonania dla obu zapytań.

Z mojego doświadczenia z Oracle 10 i 11 plany wykonania są zawsze takie same.

Answer 2

Teoretycznie każde podzapytanie może zostać zmienione na zapytanie łączące.

Answer 3

Wydajność, nie ma żadnej różnicy w większości nowoczesnych silników DB.

Answer 4

Problem z podzapytaniami polega na tym, że możesz zakończyć działanie podrzędnego zestawu bez żadnego klucza, więc dołączenie do nich będzie droższe.

Jeśli to możliwe, zawsze staraj się tworzyć zapytania JOIN i filtrować przy użyciu klauzuli ON, zamiast WHERE (chociaż powinno być to takie samo, jak w tym przypadku zoptymalizowane są nowoczesne silniki).

Answer 5

Tak jak wiele rzeczy, to zależy. - jak złożone jest podzapytanie - w zapytaniu, jak często jest wykonywane podzapytanie. Próbuję unikać podkwerend, kiedy tylko mogę. Zwłaszcza gdy oczekują dużych zestawów wyników nigdy nie używaj podkwerend - w przypadku, gdy podzapytanie jest wykonywane dla każdego elementu zestawu wyników.

dbać, Alex

Answer 6

W SQL Server podzapytanie skorelowane zwykle wykonuje gorzej niż przyłączyć lub często nawet lepsze pod kątem wydajności, sprzężenie do tabeli pochodnej. Prawie nigdy nie piszę podkwerendy dla wszystkiego, co będzie trzeba wykonać wiele razy. Dzieje się tak dlatego, że skorelowane podkwerendy często w zasadzie przekształcają zapytanie w kursor i uruchamiają jeden wiersz na raz. W bazach danych zwykle lepiej jest robić rzeczy w sposób oparty na zestawach.

Answer 7

Zignorujmy teraz wpływ na wydajność (tak jak powinniśmy, jeśli zdajemy sobie sprawę, że "przedwczesna optymalizacja jest źródłem wszelkiego zła").

Wybierz to, co wygląda jaśniej i łatwiej je konserwować.

Answer 8

Pierwsza zasada to "Dokładnie podaj zapytanie". Drugą zasadą jest "proste i oczywiste sformułowanie zapytania" (gdzie zwykle dokonuje się wyborów). Trzeci to "wypowiedz zapytanie, aby działało wydajnie".

Jeśli jest to dbms z dobrym procesorem kwerendy, równoważne projekty kwerend powinny powinny skutkować planów kwerend, które są takie same (lub co najmniej równie skuteczne).

Moja największa frustracja związana z używaniem MySQL po raz pierwszy była świadoma, że ​​muszę być uprzedzony wobec optymalizatora. Po długich doświadczeniach z produktami Oracle, SQL Server, Informix i innymi produktami DBMS, bardzo rzadko spodziewałem się zajmować takimi problemami. Teraz jest lepiej z nowszymi wersjami MySQL, ale wciąż jest to coś, z czym muszę częściej zwracać uwagę, niż na inne.