Currenlty Używam wielu sprzężeń wewnętrznych (około 7) w moim sp, czy ma to jakikolwiek wpływ na wydajność sp. czy lewe sprzężenie zewnętrzne daje lepszą wydajność niż połączenie wewnętrzne.Czy wystąpił jakiś problem z Inner Join?
jeszcze jedna rzecz, jeśli dołączam dwie tabele a i b, które mają id kolumny i id1, nie r null. Przypuszczam, że tutaj mogę przejść do sprzężenia wewnętrznego, ponieważ te kolumny są indeksowane.
Po pierwsze, te dwie są przeznaczone do różnych celów. Dlatego porównanie może nie być prawidłowe we wszystkich przypadkach.
Możesz przeczytać więcej tutaj.
sprzężenia zewnętrzne są droższe niż wewnętrzna łączy. To, co powiem, będzie dla wielu kontrowersyjne. Jeśli dostroisz bazę danych poprawnie i jeśli nie zrobisz niczego głupiego i jeśli używasz profesjonalnej siły RDBMS, wtedy 7 wewnętrznych połączeń nie powinno stanowić problemu.
Co mam na myśli przez dostrajanie bazy danych? Istnieje wiele kwestii związanych z dostrajaniem bazy danych, ale najbardziej oczywistą rzeczą do sprawdzenia jest upewnienie się, że zawsze dołączasz do kolumn, które są indeksowane.
Co mam na myśli przez głupkowaty? Nie używaj operatora OR w stanie złączenia. Staraj się trzymać połączenia za pomocą pojedynczego porównania, takiego jak klucz obcy w jednej tabeli, co równa się kluczowi podstawowemu w drugiej tabeli. Staraj się, aby wszystkie twoje kluczowe pola były wpisane jako liczby całkowite.
Jeśli wystąpią problemy z wydajnością, należy zapoznać się z planem wykonywania niepoprawnej kwerendy. Na przykład możesz napotkać problemy podczas dołączania do naprawdę dużych tabel, tak dużych, że nawet skanowanie indeksu jest zbyt wolne. Być może trzeba będzie zdenormalizować i zapewnić dodatkowe filtrowanie, aby zmniejszyć czas skanowania. Nie próbuj przewidywać tego. Denormalizacja najlepiej jest wykonać tylko i wyłącznie po uruchomieniu w rzeczywistych sytuacjach wydajności.
Gdzie była ta kontrowersyjna część? Liczba złączeń? Myślę, że to zależy tylko od tego, jakie tabele są połączone. Również dobra rada dotycząca klauzul "OR". Są zwodniczo kosztowne, szczególnie w SQL Server. – Eric
W przeszłości współpracowałem z programistami, którzy uważali, że nie powinieneś przekraczać trzech złączeń ze względu na wydajność. Zgodziłbym się z tym w latach 80., ale nie dzisiaj. – Glenn
JOIN służy do określonego celu & nie do wydajności.
LEFT OUTER JOIN służy do dołączania rekordów, dla których nie ma pasujących rekordów w tabeli po prawej stronie. INNER JOIN wybiera pasujące rekordy na podstawie niektórych kryteriów, w obu tabelach.
Ten mały smakołyk na temat LEFT OUTER JOIN był dla mnie bardzo pomocny. Przełączenie na ZEWNĘTRZNE POŁĄCZENIE z INNER JOIN obcina moje zapytanie od 16 sekund do 50 ms. Nie szukałem na kolumnach połączonego stołu, aby można było połączyć je po fakcie. –
Aby sprawdzić, co to jest Glenn said, jeśli dołączasz do "głupkowatych rzeczy", możesz również wydobyć je z tabel tymczasowych z wyprzedzeniem.
W jednej bazie danych, nad którą pracowałem w przeszłości, łączenie odbywało się na częściowym kluczu (tablice zawierały klucze złożone, tj. Klucz podstawowy z wieloma kolumnami), a w klauzuli where istniało dodatkowe filtrowanie. Filtrowanie w klauzuli where pobierało zestaw wierszy do obejrzenia od kilku miliardów do kilku tysięcy po jednej stronie sprzężenia. Dołączenie do stołu z kilkoma tysiącami rzędów było znacznie łatwiejsze niż na kilka miliardów. Czas zapytania wyniósł od 20 minut do 7 sekund, jak pamiętam.
Zauważmy, że mamy tam także podzapytania i funkcje UDF (funkcje zdefiniowane przez użytkownika) - co prawdopodobnie dodało głupstwa.
Lewe łączenia dają inne wyniki niż połączenia wewnętrzne, więc nie powinny być używane jako substytut. Najprawdopodobniej jest to indeksowanie, którego potrzebujesz. Indeksy są tworzone automatycznie podczas definiowania klucza podstawowego, ale nie są tworzone podczas definiowania klucza obcego. Będziesz musiał zindeksować wszystkie klucze do foregin w swoich połączeniach, jeśli jeszcze tego nie zrobiłeś.
Sprawdź również swój plan wykonania, aby zobaczyć, gdzie jest problem.
Aby uzyskać bardziej szczegółowe porady dotyczące sposobów dostrajania zapytania, musisz je nam pokazać.
Powodem, dla którego łączenie jest zazwyczaj drogie, jest to, że łączenie może spowodować, że liczba krotek będzie większa niż rozmiar jednej z tych tabel.
Jednak czasami atrybuty łączenia w jednej tabeli funkcjonalnie określają unikatową krotkę w innej tabeli. w takim przypadku join może być bardzo tani (ale musisz indeksować te atrybuty).
To byłaby tania operacja niezależnie od liczby połączeń, które zrobiłeś - to bardziej kwestia zależności danych i danych.
Ponieważ dołączasz do 2 kluczy, gdzie wygląda na to, że ten sam klucz jest używany w obu tabelach, powinna to być tania operacja, niezależnie od rodzaju łączenia, z którego korzystasz.
czy masz indeksy w kolumnach używanych dla warunku łączenia (jak również każdej kolumny używanej dla innego warunku, jak w klauzuli where)? może * naprawdę * pomóc. Ogólnie rzecz biorąc, słyszałem, że wewnętrzna strona jest lepsza pod względem wydajności niż po lewej stronie - ale to, co powinno być używane, zależy od tego, co chcesz uzyskać. ^^ –