MySQL: Ile zapytań na stronę jest za dużo?

Question

Jestem nowy w MySQL i coś, co szybko staje się dla mnie oczywiste, to to, że znacznie łatwiej jest stworzyć kilka zapytań do bazy danych na stronę, a nie kilka z nich ... ale tak naprawdę nie mam wyczucia ile zapytań może być za dużo, lub w którym momencie powinienem zainwestować cenniejszy czas na łączenie zapytań, spędzanie czasu na szukaniu sprytnych połączeń itd.

Zastanawiam się więc, czy są jakieś "mentalne punkty odniesienia" doświadczeni ludzie tutaj używają w odniesieniu do liczby zapytań na stronę, a jeśli tak, to ile ich może być za dużo?

Rozumiem, że poprawna odpowiedź w dowolnym kontekście jest związana z tym, co jest potrzebne do spełnienia wymagań funkcjonalnych aplikacji. Jednak w przypadku projektów, w których wymagania klienta mogą być elastyczne lub niewłaściwie ustawione, lub w przypadku projektów, w których jako deweloper obowiązuje pełna kontrola (np. Witryny opracowane dla siebie), możliwe jest negocjowanie między funkcjonalnością a wydajnością ... po prostu wyciąć trywialne funkcje, jeśli wymagania dotyczące kodowania wpływają na wydajność i nie jesteś w stanie zoptymalizować go.

Byłbym wdzięczny za wszelkie opinie w tej sprawie.

Dzięki

Answer 1

Zależy od tego, jak często strona jest używana, opóźnienia między serwerem aplikacji i serwerem bazy danych oraz wiele innych czynników.

Dla strony, która wyświetla tylko dane, mam przeczucie, że 100 to za dużo. Jednak są pewne przypadki, w których może to być dopuszczalne.

W praktyce należy optymalizować tylko w razie potrzeby, co oznacza, że ​​należy zoptymalizować strony, z których ludzie korzystają najwięcej, i zignorować te drugorzędne.

W szczególności strony nie są dostępne publicznie, a (niewielu) upoważnionych użytkowników rzadko korzysta z nich, nie ma motywacji, aby je przyspieszyć.

Jeśli jest to prawdziwy problem wydajność który wierzysz pochodzi od zbyt wielu zapytań, należy włączyć rejestr ogólnego zapytania (mogące powodować gorsze osiągi, obawiam się) i analizować najczęściej odpytuje z myślą o eliminując je.

Może się okazać, że są pewne "nisko wiszące owoce" - proste zapytania na rzadko zmieniających się danych, które są wywoływane na najpopularniejszych stronach, które można łatwo wyeliminować (na przykład, czy serwer aplikacji pobiera dane z crona Zadanie do lokalnego pliku i odczytanie go z tego miejsca). Lub nawet "niższe wiszące owoce", takie jak zapytania, które są zupełnie niepotrzebne.

Trudność przy próbie połączenia wielu zapytań polega na tym, że ma ona skłonność do wielokrotnego używania kodu i możliwości konserwacji kodu, więc należy to robić tylko wtedy, gdy jest to absolutnie konieczne; nie brzmi to tak, jakbyś miał wystarczająco dużo danych, aby dokonać tej determinacji.

Answer 2

Nie ma zestaw numer, „strona” jest dosyć arbitralne - można robić jedno zadanie bazy danych, podczas gdy inny może mieć 2 tuziny widgets każdy z własnym zadaniu.

Jedna dobra zasada: w momencie umieszczenia SELECT w pętli, która przetwarza wiersze innego SELECT, zatrzymaj się. Na początku może się to wydawać wystarczająco szybkie, ale dane mają tendencję do wzrostu, a te zagnieżdżone pętle rosną wraz z nim wykładniczo, więc spodziewaj się, że w pewnym momencie stanie się wąskim gardłem. Nawet jeśli pojedyncze zapytanie kończy się znacznie wolniej, na dłuższą metę będzie lepiej (i zawsze są przechowywane procesy, buforowanie zapytań itp.).