Eksperci wiedzą, jak pisać wydajne zapytania. Chociaż doświadczenie dojrzewa mądrość, są pewne rzeczy, które trzeba zrozumieć przynajmniej na początku. Na przykład musisz zrozumieć kluczowe kwestie dotyczące projektowania zapytań; w jaki sposób zapytanie wykonuje się wewnętrznie, gdzie kończy się niepowodzeniem, wzorce optymalizacji itp. W tym artykule przedstawię kilka punktów optymalizacji do rozważenia podczas projektowania zapytania w MySQL.
Dlaczego niektóre zapytania są wolne?
Częstym problemem związanym z zapytaniami SQL jest to, że pobieranych jest więcej danych, niż jest to faktycznie potrzebne. Oczywiście są zapytania, które przesiewają wiele danych i niewiele możemy z nimi zrobić, ale nie są one powszechne. W większości przypadków to zły projekt zapytania prowadzi do słabej wydajności zapytania. Po każdym projekcie zapytania należy przeprowadzić introspekcję kilku aspektów, na przykład tego, co może się stać po uruchomieniu zapytania:
- Czy zapytanie SQL będzie miało dostęp do zbyt wielu kolumn lub wierszy?
- Czy serwer MySQL przeanalizuje zbyt wiele wierszy, aby pobrać żądany wynik?
Istnieją zapytania, które powodują, że serwer MySQL analizuje zbyt dużo danych, ale rzuca je podczas przesiewania. Jest to dodatkowa praca dla serwera w wielu aspektach, takich jak obciążenie sieci, zbyt duże zużycie pamięci lub zbyt duże wykorzystanie zasobów procesora na serwerze. Konsekwencją jest niska wydajność.
Są sytuacje, w których możesz nie być w stanie wiele pomóc podczas jego projektowania, ale jest sytuacja, w której jeśli będziesz ostrożny i oszacujesz konsekwencje oraz dokonasz introspekcji, wtedy złe zapytanie może być przynajmniej dobre, jeśli nie lepsze.
Typowe błędy i ich rozwiązania
Podczas pisania zapytania często popełnia się kilka typowych błędów. Oto kilka z nich. Możesz znaleźć kilka innych myśli na tej samej linii. Oto powody niskiej wydajności zapytań z możliwymi rozwiązaniami.
Za dużo wierszy
Często popełniany jest błąd polegający na pisaniu zapytania, które pobiera dane i zakłada, że MySQL dostarczy wynik na żądanie, pomijając jednocześnie ilość przetwarzania wymaganą do zwrócenia pełnego zestawu wyników. Załóżmy, że instrukcja SELECT jest uruchamiana w celu pobrania szczegółów 100 produktów dla witryny e-commerce, podczas gdy tylko 10 z nich musi być wyświetlonych jako pierwsze. Możesz pomyśleć, że MySQL pobiera tylko 10 wierszy i przestaje wykonywać zapytanie. Ale nie. To, co robi MySQL, to generowanie pełnego zestawu wyników i karmienie klienta. Biblioteka kliencka otrzymuje kompletny zestaw i odrzuca większość z nich, zachowując tylko 10 z których szuka. To oczywiście marnuje dużo zasobów.
Jednak w takiej sytuacji możesz podać rozwiązanie, używając klauzuli LIMIT w zapytaniu.
SELECT col1, col2,... FROM table_name LIMIT [offset,] count;
Klauzula LIMIT akceptuje jeden lub dwa parametry. Pierwsza określa przesunięcie, a druga liczbę. Jeśli określony jest tylko jeden parametr, oznacza to liczbę wierszy od początku zestawu wyników.
Na przykład, aby wybrać 10 wierszy z tabeli, możesz napisać:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10;
Aby wybrać kolejne 10 wierszy, zaczynając od 11 rekordu, możesz napisać:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10, 10;
Zbyt wiele kolumn
Zawsze patrz na zapytanie:SELECT * z podejrzliwością. To zapytanie zwraca wszystkie kolumny i prawdopodobnie potrzebujesz tylko niektórych z nich. Największą wadą pobierania wszystkich kolumn jest to, że uniemożliwia optymalizację, utrudniając korzystanie z indeksów, wymaga zbyt dużej ilości zasobów we/wy, pamięci i procesora z serwera.
Zrozum, że takie uniwersalne zapytanie pobierające wszystkie kolumny może być marnotrawstwem. Niektórzy twierdzą, że są przydatne, ponieważ pozwalają programistom na użycie tego samego fragmentu kodu w więcej niż jednym miejscu. To w porządku, jeśli związane z tym koszty są ograniczone. Czasami buforowanie pobranych danych pomaga w tym kontekście. Ale bądź ostrożny, wykorzystanie wydajności to elegancka praca, a taki luksus może nie mieć miejsca na wydajność.
Ogólną zasadą jest unikanie takich uniwersalnych zapytań lub ograniczenie liczby pobieranych kolumn do minimum.
Za dużo analizy danych
Zapytania zwracają pożądany wynik, co jest w porządku, ale czasami te zapytania są napisane w taki sposób, że przetwarzanie ich wymaga zbadania zbyt dużej ilości danych przed wygenerowaniem wyników. Dlatego w MySQL musisz mierzyć zgodnie z następującymi metrykami kosztów:
- Czas wykonania
- Sprawdzone wiersze
- Zbadane kolumny
Na podstawie tych metryk można uzyskać przybliżone oszacowanie kosztu zapytania. Odzwierciedla to ilość dostępu do danych przez MySQL wewnętrznie w celu przetworzenia zapytania oraz szybkość działania zapytania. Ponieważ te metryki są rejestrowane w dzienniku powolnych zapytań, dobrym pomysłem jest zbadanie i znalezienie zapytań, które analizują zbyt dużo danych, aby zwrócić wynik. Baza danych MySQL rejestruje wszystkie zapytania, które przekraczają zadany czas wykonania w wolnym dzienniku zapytań. To idealne miejsce do wyszukiwania powolnych zapytań i sprawdzania, jak często są powolne.
Dziennik powolnych zapytań zwykle znajduje się w /var/log/mysql/mysql-slow.log
Zauważ, że może być konieczne ustawienie i włączenie rejestrowania powolnych zapytań w mysqld.cnf plik konfiguracyjny w następujący sposób.
#slow_query_log = 1 #slow_query_log_file = /var/log/mysql/mysql-slow.log #long_query_time = 2
Przed i z MySQL 5 istniały poważne ograniczenia, zwłaszcza brak obsługi szczegółowego logowania. Jedynym wytchnieniem było używanie łatek umożliwiających logowanie. Jednak funkcja ta była częścią serwerów MySQL 5.1 i nowszych jako część jej podstawowej funkcji.
Zapytania, których wykonanie zajmuje zbyt dużo czasu, niekoniecznie oznacza, że są to złe zapytania. Powolny dziennik zapytań zapewnia po prostu możliwość zbadania wydajności zapytań i poprawienia jej w miarę możliwości.
Restrukturyzacja zapytań
Ponieważ masz możliwość restrukturyzacji problematycznych zapytań, Twoim głównym celem powinno być znalezienie alternatywnego rozwiązania, aby osiągnąć pożądany efekt. Możesz przekształcić zapytanie do jego równoważnej postaci, pamiętając o wewnętrznym efekcie na serwerze MySQL podczas przetwarzania.
Jedną z decyzji w projektowaniu zapytań jest to, czy powinniśmy preferować jedno złożone zapytanie zamiast kilku prostych, czy odwrotnie. Konwencjonalne podejście do projektowania baz danych polega na wykonaniu jak największej liczby prac przy mniejszej liczbie zapytań. Powodem jest to, że jedno duże/złożone zapytanie jest bardziej opłacalne pod względem nawiązywania połączenia z bazą danych. Zaletą redukcji kosztów na rzecz złożonych zapytań jest wykorzystanie sieci, przetwarzanie/optymalizacja zapytań oraz wykorzystanie zasobów. Ale to tradycyjne podejście nie pasuje do MySQL. MySQL został zaprojektowany do szybkiej obsługi połączeń i rozłączeń z bazą danych. Dlatego nawiązywanie połączenia, uruchamianie wielu prostszych zapytań i zamykanie połączenia wydaje się bardziej efektywne. Pobieranie danych przez więcej niż jedno proste zapytanie zamiast jednego dużego złożonego jest bardziej efektywne. Pamiętaj, że ten sam pomysł nie może być zastosowany w innych bazach danych.
Wniosek
Oto kilka krótkich wskazówek dotyczących optymalizacji zapytań. Zrozum, że znajomość składni SQL, możliwość stworzenia zapytania, które zwraca pożądany wynik, nie wystarczy, jeśli dąży się do wydajności zapytania. Zrozumienie tego, co dzieje się pod pozornie prostymi zapytaniami, jest niezbędne do napisania takiego, które nie tylko odzyska to, co jest pożądane, ale nasyci sztukę optymalizacji od samego początku. Zakulisowe przetwarzanie zapytań daje ważną wskazówkę, aby zrozumieć wydajność zapytań, a ta wiedza jest niezbędna przed wejściem w dziedzinę optymalizacji zapytań.
