Pracowałem dla różnych firm i zauważyłem, że niektóre z nich wolą mieć poglądy, które dołączą do stołu ze wszystkimi „krewnymi”. Ale w przypadku aplikacji czasami musimy użyć tylko 1 kolumny.

Czy byłoby więc szybsze dokonanie prostych wyborów, a następnie „dołączenie” ich do kodu systemowego?

Systemem może być php, java, asp, dowolny język łączący się z bazą danych.

Pytanie brzmi: co szybciej przechodzi ze strony serwera (php, java, asp, ruby, python ...) do bazy danych, uruchom jedno zapytanie, które dostanie wszystko, czego potrzebujemy, lub przejdź ze strony serwera do bazy danych i uruchom zapytanie, które jednocześnie pobiera kolumny tylko z jednej tabeli?

To, co odpowiedziałoby na twoje pytanie, to temat DOŁĄCZ DO ROZKŁADU.

Według strony 209 książki

Możesz dekomponować złączenie, uruchamiając wiele zapytań pojedynczej tabeli zamiast łączenia wielodostępnego, a następnie wykonując połączenie w aplikacji. Na przykład zamiast tego pojedynczego zapytania:

SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id = tag.id
JOIN post ON tag_post.post_id = post.id
WHERE tag.tag = 'mysql';

Możesz uruchomić następujące zapytania:

SELECT * FROM tag WHERE tag = 'mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);

Dlaczego, u licha, miałbyś to robić? Na pierwszy rzut oka wygląda to na marnotrawstwo, ponieważ zwiększyłeś liczbę zapytań, nie otrzymując nic w zamian. Jednak taka restrukturyzacja może w rzeczywistości dać znaczące korzyści w zakresie wydajności:

• Buforowanie może być bardziej wydajne. Wiele aplikacji buforuje „obiekty”, które są mapowane bezpośrednio na tabele. W tym przykładzie, jeśli obiekt ze znacznikiem mysqljest już buforowany, aplikacja pominie pierwsze zapytanie. Jeśli znajdziesz w pamięci podręcznej posty o identyfikatorze 123, 567 lub 908, możesz usunąć je z IN()listy. Pamięć podręczna zapytań może również skorzystać z tej strategii. Jeśli tylko jedna z tabel zmienia się często, dekompozycja złączenia może zmniejszyć liczbę unieważnień pamięci podręcznej.
• Wykonywanie zapytań indywidualnie może czasem zmniejszyć rywalizację o blokadę
• Wykonanie złączeń w aplikacji ułatwia skalowanie bazy danych poprzez umieszczenie tabel na różnych serwerach.
• Same zapytania mogą być bardziej wydajne. W tym przykładzie użycie IN()listy zamiast łączenia pozwala MySQL sortować identyfikatory wierszy i pobierać wiersze bardziej optymalnie, niż byłoby to możliwe w przypadku łączenia.
• Możesz ograniczyć zbędny dostęp do wierszy. Wykonanie sprzężenia w aplikacji oznacza pobranie każdego wiersza tylko raz., Natomiast sprzężenie w zapytaniu jest zasadniczo denormalizacją, która może wielokrotnie uzyskiwać dostęp do tych samych danych. Z tego samego powodu taka restrukturyzacja może również zmniejszyć całkowity ruch sieciowy i zużycie pamięci.
• Do pewnego stopnia można zobaczyć tę technikę jako ręczne wdrażanie sprzężenia mieszającego zamiast algorytmu zagnieżdżonych pętli, którego MySQL używa do wykonania sprzężenia. Łączenie mieszające może być bardziej wydajne.

W rezultacie sprzężenia czynności w aplikacji mogą być bardziej wydajne, gdy buforujesz i ponownie wykorzystujesz wiele danych z wcześniejszych zapytań, rozprowadzasz dane na wiele serwerów, zamieniasz IN()sprzężenia na listy lub sprzężenie odnosi się wielokrotnie do tej samej tabeli.

OBSERWACJA

Podoba mi się pierwszy punktor, ponieważ InnoDB jest trochę ciężki, gdy sprawdza pamięć podręczną zapytania.

• Sep 05, 2012: Czy narzut związany z częstym unieważnianiem pamięci podręcznej zapytań jest kiedykolwiek tego wart?
• Jun 07, 2014: Dlaczego domyślnie wyłączona jest opcja query_cache_type, zaczynamy od MySQL 5.6?

Jeśli chodzi o ostatni punkt, napisałem post 11 marca 2013 r. ( Czy istnieje różnica w wykonywaniu między warunkiem JOIN a warunkiem WHERE? ), Który opisuje algorytm zagnieżdżonej pętli. Po przeczytaniu zobaczysz, jak dobry może być rozkład złączeń.

Podobnie jak w przypadku wszystkich innych punktów z książki , programiści naprawdę szukają wydajności jako dolnej linii. Niektóre polegają na zewnętrznych środkach (poza aplikacją) w celu zwiększenia wydajności, takich jak użycie szybkiego dysku, uzyskanie większej liczby procesorów / rdzeni, dostrojenie silnika pamięci i dostrojenie pliku konfiguracyjnego. Inni zapinają się i piszą lepszy kod. Niektórzy mogą uciekać się do kodowania całej analizy biznesowej w Procedurach składowanych, ale nadal nie stosują dekompozycji łączenia (zobacz Jakie argumenty przemawiają przeciwko lub za umieszczeniem logiki aplikacji w warstwie bazy danych? Wraz z innymi postami). Wszystko zależy od kultury i tolerancji każdego sklepu programisty.

Niektórzy mogą być zadowoleni z wydajności i nie dotykać kodu. Inni po prostu nie zdają sobie sprawy z wielkich korzyści, które można czerpać, jeśli spróbują dołączyć do kompozycji.

Dla programistów, którzy chcą ...

SPRÓBUJ !!!

W Postgres (i prawdopodobnie w dowolnym RDBMS w podobnym stopniu, MySQL w mniejszym stopniu) mniej zapytań jest prawie zawsze znacznie szybszych.

Narzut związany z analizowaniem i planowaniem wielu zapytań jest już większy niż jakikolwiek możliwy zysk w większości przypadków.

Nie mówiąc już o dodatkowej pracy do wykonania u klienta, łącząc wyniki, które zwykle są znacznie wolniejsze. RDBMS specjalizuje się w tego rodzaju zadaniach, a operacje są oparte na oryginalnych typach danych. Brak rzutowania do texti z powrotem dla wyników pośrednich lub przekształcania do rodzimych typów klienta, co może nawet prowadzić do mniej poprawnych (lub niepoprawnych!) Wyników. Pomyśl o liczbach zmiennoprzecinkowych ...

Przesyłasz także więcej danych między serwerem DB a klientem. Może to być nieistotne w przypadku ręki pełnej wartości lub mieć ogromną różnicę.

Jeśli wiele zapytań oznacza wiele podróży w obie strony do serwera bazy danych, zbierasz również wielokrotnie opóźnienie sieci i narzut transakcji, być może nawet narzut połączenia. Wielka, wielka strata.

W zależności od konfiguracji samo opóźnienie sieci może trwać dłużej niż cała reszta o rząd wielkości.

Powiązane pytanie dotyczące SO:

• Który jest lepszy? Wykonywanie obliczeń w sql lub w aplikacji

Punktem zwrotnym mogą być bardzo duże , długo działające zapytania, ponieważ po drodze transakcje zbierają blokady wierszy DB. Bardzo duże zapytania mogą zawierać wiele blokad przez dłuższy czas, co może powodować tarcie przy równoczesnych zapytaniach .