Jak profilować zapytania SQL w celu uzyskania lepszej wydajności

Opublikowany: 2023-03-16

W Servebolt żyjemy i oddychamywydajnością .

Wydajność bazy danych nie jest wyjątkiem.

Wykonanie nieefektywnego zapytania po kliknięciu linku przez odwiedzającego witrynę znacznie pogorszy wrażenia użytkownika .Będą musieli poczekać na wykonanie całego powolnego zapytania, co może potrwać kilka sekund, zanim nastąpi jakakolwiek inna akcja, taka jak renderowanie strony. Ten czas oczekiwania obejmuje nie tylko czas potrzebny do wykonania zapytania, ale także dodatkowy czas potrzebny na przetwarzanie wstępne i przetwarzanie końcowe. W rezultacie źle zaprojektowane zapytanie może znacznie spowolnić ogólną wydajność witryny, co skutkuje frustrującym doświadczeniem użytkownika.

Time to First Byte (TTFB) to sposób mierzenia, ile czasu zajmuje otrzymanie pierwszego bajtu danych po przesłaniu przez użytkownika żądania do witryny internetowej.Jest to również kluczowy wskaźnik używany przez wyszukiwarki do oceny witryn. Uruchomienie powolnego zapytania wpłynie negatywnie na TTFB. Im dłużej trwa powolne zapytanie, tym wyższy będzie TTFB, co skutkuje mniejszą ogólną wydajnością witryny i mniej satysfakcjonującym doświadczeniem użytkownika.

W tym przewodniku przeprowadzimy Cię przez proces profilowania zapytań SQL — kluczowej części utrzymywania wydajności aplikacji internetowych, które opierają się na odpowiedziach bazy danych. Jest to proces, który tworzy podstawy, aby następnie móc rozpocząć pracę nad optymalizacją tych zapytań w celu poprawy ich wydajności.

Zrozumienie profilowania zapytań SQL

Gdy tworzysz aplikację internetową i zaczyna ona działać na większą skalę, zapytania SQL, które kiedyś działały płynnie, mogą powodować problemy z wydajnością. Ogólnie rzecz biorąc, rośnie liczba zapytań uruchamianych w odniesieniu do rosnącej ilości danych przy rosnącej liczbie żądań na sekundę. A gdy spada wydajność, cierpią na tym również wrażenia użytkowników podczas interakcji z Twoją witryną, oprogramowaniem lub usługą.

Profilowanie zapytań to sposób analizowania zapytań do bazy danych, oceny ich wydajności i identyfikowania potencjalnych problemów.

Analizując i identyfikując te problematyczne zapytania, możesz wprowadzić konkretne ulepszenia, które mogą mieć wymierny wpływ na wydajność ich bazy danych. To z kolei pozwoli na lepszą skalowalność w przyszłości, a także ogólną satysfakcję klientów, ponieważ aplikacje i witryny będą bardziej responsywne.

MariaDB (i MySQL) udostępniają kilka narzędzi i technik profilowania zapytań, które omówimy w tym artykule. Po zidentyfikowaniu wolnych zapytań następnym krokiem będzie ich optymalizacja. Ten proces obejmuje zidentyfikowanie głównej przyczyny problemu i wprowadzenie zmian w strukturze zapytań w celu poprawy ich wydajności.

Jak profilować zapytania SQL (7 metod)

Zacznijmy od rozbicia różnych narzędzi i technik, które są dostępne do identyfikowania powolnych i nieefektywnych zapytań, abyś wiedział, gdzie skoncentrować działania usprawniające:

1 – Polecenie WYJAŚNIJROZSZERZENIE

Jednym z narzędzi, które można wykorzystać do analizy zapytań SQL, jest polecenieEXPLAIN .

Uruchamiając polecenie EXPLAIN na zapytaniu, można zobaczyć, w jaki sposób zapytanie jest wykonywane, w tym używane indeksy i liczbę sprawdzanych wierszy.

EXPLAIN SELECT * FROM orders

JOIN customers ON orders.customer_id = customers.customer_id

WHERE customers.name = 'John Smith';

Uruchomienie polecenia EXPLAINw zapytaniu zwraca zestaw wyników z kilkoma kolumnami, w tym:

  • id: unikalny identyfikator zapytania w planie wykonania
  • typ_wyboru: typ zapytania, na przykład PROSTE lub PODZAPYTANIE
  • table: Tabela, której dotyczy zapytanie
  • type: używany typ łączenia, taki jak JOIN lub INDEX
  • możliwe_klucze: Indeksy, których MariaDB lub MySQL mogły użyć do przetworzenia zapytania
  • key: Indeks, którego MariaDB lub MySQL faktycznie użyły do ​​przetworzenia zapytania
  • key_len: Długość użytego klucza
  • wiersze: liczba wierszy, które według szacunków MariaDB lub MySQL zostaną zbadane dla zapytania

Extra: Zawiera dodatkowe informacje o zapytaniu, takie jak to, czy wykonano pełne skanowanie tabeli lub czy użyto tabeli tymczasowej.

Analizując dane wyjściowe poleceniaEXPLAIN, można zazwyczaj zidentyfikować potencjalne wąskie gardła wydajności, takie jak słabe indeksowanie, nieoptymalne typy łączenia lub duża liczba badanych wierszy.

Na przykład, jeśli kolumna typu zawiera „ALL” zamiast „indeks”,oznacza to, że zapytanie wykonuje pełne skanowanie tabeli, co prawie na pewno spowoduje spowolnienie działania. Jeśli kolumna klucza ma wartość NULL, oznacza to, że MySQL nie używa żadnych indeksów, co również będzie wolne. Jeśli kolumna wierszy ma wysoką wartość, oznacza to, że analizowanych jest wiele wierszy, co powoduje dalsze pogorszenie wydajności.

Wolimy używać wariantu EXPLAIN EXTENDED , aby uzyskać dodatkowe informacje.

Uwaga: Chociaż jest to przestarzałe w MySQL, nadal jest dostępne w MariaDB.

Korzystając z opcji ROZSZERZENIE, będziesz mógł zobaczyć przydatne informacje, takie jak liczba zbadanych wierszy, liczba zwróconych wierszy, informacje o zastosowanym typie JOIN, kolejności przeskanowanych tabel, użytych indeksach i czasie zapytanie miało zostać wykonane.

Oto jak wygląda użycie polecenia EXPLAIN EXTENDED:

EXPLAIN EXTENDED SELECT * FROM your_table WHERE column_name = 'value';

W tym przykładzie polecenie EXPLAIN wyświetli listę kroków, które baza danych wykona w celu wykonania zapytania, a także listę zasobów, z których będzie korzystać.

Korzystając z tego polecenia, łatwiej będzie wykryć wąskie gardła w zapytaniu, umożliwiając wprowadzenie wszelkich niezbędnych zmian, które pomogą złagodzić to i przyspieszyć działanie zapytania.

Na przykład użycie polecenia EXPLAIN EXTENDED może pomóc zidentyfikować potrzebę dodania indeksów, zoptymalizować warunki JOIN i ograniczyć całkowitą liczbę wierszy zwracanych przez zapytanie.

Należy również upewnić się, że wyłączono buforowanie zapytań podczas przeprowadzania tych testów i optymalizacji, aby uzyskać dokładne wyniki. Aby to zrobić, najpierw uruchom to polecenie po podłączeniu klienta.

SET SESSION query_cache_type=0;

Po wprowadzeniu tych zmian w zapytaniu ponownie przetestuj jego wydajność, aby określić, w jakim stopniu osiągnięto poprawę (jeśli w ogóle). Pamiętaj, że podobnie jak w przypadku każdego profilowania i optymalizacji zapytania, proces jest iteracyjny — spodziewaj się kilkukrotnego użycia polecenia EXPLAIN EXTENDED, po którym następuje test wydajności.

2 – PolecenieWYJAŚNIJ ANALIZĘ

To polecenie służy do analizowania planu wykonania zapytania i zwracania metryk wydajności, takich jak rzeczywisty czas wykonania zapytania i liczba rzeczywiście zbadanych wierszy. Analizując wyniki polecenia EXPLAIN ANALYZE, można zidentyfikować potencjalne wąskie gardła w wykonaniu zapytania, takie jak brak indeksów lub duża liczba wierszy do sprawdzenia.

3 – Dziennik powolnych zapytań

Jest to wbudowana funkcja w MariaDB (i MySQL), która rejestruje wszystkie zapytania, których wykonanie trwa dłużej niż określony czas. Dziennik powolnych zapytań można skonfigurować do rejestrowania zapytań, które trwają dłużej niż określony próg, na przykład jedną sekundę.

W Servebolt powolny dziennik zapytań rejestruje wszystkie zapytania, których wykonanie trwa dłużej niż 1 sekundę. Wynika to z faktu, że większość zapytań powinna być wykonywana w ułamkach sekundy. W kontekście aplikacji internetowej, takiej jak witryna z systemem WordPress, ładowanie pojedynczej strony wymaga od 10 do 100 zapytań do bazy danych, z których wszystkie muszą być wykonywane sekwencyjnie, zanim strona będzie mogła zostać skompilowana do formatu HTML i zwrócona użytkownikowi.

Obecna konfiguracja Servebolt Cloud przechowuje dzienniki powolnych zapytań na globalnym serwerze dzienników. Jeśli zajdzie taka potrzeba, możesz po prostu skontaktować się z naszym zespołem pomocy technicznej, a my przefiltrujemy plik pod kątem odpowiednich dzienników i dostarczymy dane wyjściowe.

We własnych środowiskach możesz włączyć dziennik powolnych zapytań, dodając następujące wiersze do pliku konfiguracyjnego MariaDB lub MySQL (my.cnf lub my.ini):

log_slow_queries = /path/to/slow.log

long_query_time = 1

4 – Wizualny plan wyjaśnień

Wizualny plan wyjaśniania zapewnia graficzną reprezentację danych wyjściowych polecenia EXPLAIN, ułatwiając zrozumienie wykonywania zapytania i wykrywanie wszelkich problemów z wydajnością.

Uwaga: Plany Visual Explain są pomocne podczas tworzenia aplikacji internetowych.

Zamiast zwykłego tekstu wyświetla wykonanie zapytania w strukturze drzewa , gdzie każdy węzeł reprezentuje tabelę, indeks lub operację, a połączenia między nimi przedstawiają kolejność operacji.

Różne narzędzia, takie jak MySQL Workbench i EXPLAIN Analyzer, mogą generować wizualne plany wyjaśniania i udostępniać interaktywny interfejs do poruszania się po planie wykonania i szczegółowego badania każdej operacji.

Na przykład w MySQL Workbench wygenerowanie wizualnego planu wyjaśniania jest tak proste, jak wykonanie zapytania i kliknięcie przycisku „Wyjaśnij plan ” na karcie wyników.Przedstawia graficzną reprezentację planu wykonania zapytania wraz ze szczegółowymi informacjami na temat każdej operacji. Dzięki temu można zidentyfikować wszelkie problemy z wydajnością, a następnie zoptymalizować zapytanie zgodnie z potrzebami.

5 – Tuner MySQL

MySQL Tuner to skrypt, który sprawdza wydajność i konfigurację serwera bazy danych oraz przedstawia zalecenia dotyczące ulepszeń. Zawiera podsumowanie bieżącego stanu serwera, w tym informacje takie jak łączna liczba zapytań, liczba powolnych zapytań oraz bieżące wykorzystanie puli buforów.

Można go również używać do sprawdzania różnych innych ustawień, takich jak wersja bazy danych, używany mechanizm pamięci masowej i konfiguracja pamięci podręcznej zapytań, a także zapewnia zalecenia dotyczące optymalizacji tych ustawień na podstawie bieżącego obciążenia.

Jedną z głównych różnic w stosunku do innych narzędzi jest to, że jest to narzędzie wiersza polecenia, które można uruchomić na samym serwerze lub zdalnie, co ułatwia automatyzację procesu monitorowania i optymalizacji wydajności bazy danych.

Uwaga: jeśli Twoja aplikacja internetowa (i baza danych) jest już hostowana w chmurze Servebolt – jest to coś, w czym nasz zespół się specjalizuje i jest w stanie zrobić to lepiej niż jakiekolwiek zalecenia, które narzędzie byłoby w stanie zapewnić.

6 – Profile zapytań

Istnieją narzędzia do profilowania zapytań innych firm, których można używać do profilowania zapytań SQL, takie jak MariaDB Enterprise Query Analyzer , Dataedo i Percona Toolkit . Profile zapytań innych firm mogą zapewniać dodatkowe funkcje i funkcje w porównaniu z wbudowanymi narzędziami dostępnymi w MariaDB (lub MySQL).

Uwaga: Profile zapytań są pomocne podczas tworzenia aplikacji internetowych.

Na przykład mogą oferować bardziej szczegółowe informacje o wydajności zapytań, takie jak czas wykonania i czas oczekiwania na blokadę, oraz mogą zapewniać wizualizację danych w sposób, który nie jest możliwy za pomocą wbudowanych narzędzi.

Jeśli wbudowane narzędzia są wystarczające dla Twoich potrzeb, nie ma potrzeby korzystania z zewnętrznych profilerów zapytań. Jeśli jednak potrzebujesz bardziej szczegółowych informacji lub zaawansowanych funkcji, warto rozważyć skorzystanie z zewnętrznego narzędzia do profilowania.

7 – Profilowanie za pomocą narzędzi do monitorowania

Istnieje również szereg narzędzi do monitorowania, takich jak Prometheus, Grafana i Nagios, których można używać do profilowania zapytań i monitorowania wydajności baz danych.

Prometheus to wydajny system monitorowania, który może gromadzić, przechowywać i wyszukiwać dane metryk, umożliwiając uzyskiwanie cennych informacji w czasie rzeczywistym.Integruje się z MariaDB (i MySQL) w celu przechowywania zebranych danych i jest dostarczany z Grafana do efektywnej wizualizacji.

Grafana to potężne narzędzie analityczne typu open source, którego można używać do monitorowania i wizualizacji danych zebranych z Prometheus.Konfigurowanie niestandardowych pulpitów nawigacyjnych i alertów umożliwia monitorowanie wydajności bazy danych w czasie rzeczywistym.

Nagios pomaga przez cały czas monitorować kondycję Twojej bazy danych.Można go skonfigurować do monitorowania kluczowych zasobów, takich jak procesor, pamięć RAM i miejsce na dysku, jednocześnie śledząc inne usługi i urządzenia sieciowe. Ponieważ jest wysoce konfigurowalny, jest doskonałym narzędziem do proaktywnego monitorowania zapytań do bazy danych.

Za pomocą tych narzędzi do monitorowania serwera można śledzić problemy z wydajnością i szybko podejmować działania, co pozwala zapewnić płynne działanie serwera bazy danych.

Typowe techniki optymalizacji zapytań

Istnieje kilka typowych technik optymalizacji zapytań, których można użyć do poprawy wydajności zapytań SQL:

1 – Indeksowanie

Indeksy to sposób na przyspieszenie zapytań – szczególnie tych, które korzystają z filtrów(WHERE).Korzystanie z indeksów powoduje powstanie struktur danych w silniku bazy danych (MariaDB lub MySQL) poza określonymi tabelami i wskazuje dane, które próbujesz przeszukać. W tym poście nie będziemy wchodzić w szczegóły, ponieważ używanie indeksów do ulepszania zapytań do baz danych gwarantuje osobny artykuł – coś, co planujemy omówić w przyszłości.

Rozważmy na przykład dużą tabelę o nazwie „zamówienia”, która zawiera miliony wierszy danych, w tym informacje takie jak identyfikator zamówienia, identyfikator klienta i data zamówienia. Jeśli zapytanie zostanie wykonane w celu pobrania wszystkich zamówień złożonych przez konkretnego klienta bez indeksu w kolumnie ID klienta, MariaDB musiałaby przeskanować całą tabelę, aby znaleźć odpowiednie dane. Może to zająć dużo czasu i zasobów, zwłaszcza w przypadku dużych tabel.

Mówiąc ogólnie, jeśli masz pewność, że będziesz wielokrotnie uruchamiać określone zapytanie i odczytywać dane dotyczące wydajności, utworzenie indeksu (lub więcej niż jednego) może być właściwym podejściem do przyspieszenia tego zapytania.

W kontekście WordPress jest to bardzo powszechne. Wiele wtyczek jest tworzonych przez programistów, którzy (z wygody) używają ogólnych, współdzielonych tabel bez użycia indeksów. W rezultacie jest to również obszar, w którym często następuje bardzo znaczny wzrost wydajności.

Aby wyświetlić indeksy istniejące w określonej tabeli,

Możesz wyświetlić dowolne indeksy, które istnieją w określonej tabeli, używając SHOW INDEX FROM – tak jak w poniższym przykładzie dla tabeli wp_postmeta:

MariaDB [db_name] > SHOW INDEX FROM wp_postmeta;

W jednym scenariuszu niedawno utworzyliśmy dwa indeksy dla tabeli wp_postmeta:sb_postid_metakey i sb_postid_metakey_metaval.

Indeksy te zostały dodane w oparciu o spojrzenie na najwolniejsze zapytania i stwierdzenie, że wszystkie były stosunkowo podobne pod względem właściwości instrukcji SELECT, które filtrują przy użyciu WHERE oprócz wielu warunków porównania (ORAZ/LUB). Widząc to, przejrzałem bieżące indeksy używanej tabeli i uruchomiłemEXPLAIN EXTENDED w zapytaniu, aby dalej zweryfikować moje podejście.

Zapytanie w większości działało i korzystało z tabeli wp_postmeta przy użyciuJOIN.W oparciu o kolejność, w jakiej to się działo, dodanie tych indeksów pozwoliłoby MariaDB (lub MySQL) uzyskać odpowiedź z indeksów zamiast skanowania całej tabeli ze wszystkimi jej wierszami.

CREATE INDEX sb_postid_metakey ON wp_postmeta (post_id, meta_key);

CREATE INDEX sb_postid_metakey_metaval ON wp_postmeta (post_id, meta_key, meta_value);

Jest to połączenie „rozgryzania” przy użyciu narzędzi, które masz do dyspozycji (jak opisano powyżej), a także znajomości typów danych i zawartości bazy danych. To w żadnym wypadku nie zawsze działa; nawet jeśli tak się stanie, nie zawsze skutkuje to 500% poprawą wydajności. Posiadanie ogromnego indeksu może być wolniejsze niż skanowanie wszystkich wierszy, dlatego zapytania należy przetestować przed i po zastosowaniu indeksów, aby mieć pewność.

Uwaga: podczas próby przetestowania szybkości indeksowania warto wyłączyć buforowanie zapytań dla sesji, używając:

SET SESSION query_cache_type=0;

W tym przypadku przed użyciem indeksów wykonanie zapytania zajęło 10,437 sekund. A po utworzeniu dwóch indeksów to samo zapytanie zajęło [# sekund].

2 – Ograniczanie dostępu do danych

Zmniejszenie dostępu do danych , czyli zminimalizowanie liczby wierszy i kolumn, do których należy uzyskać dostęp w celu wykonania zapytania.Można to osiągnąć, filtrując dane pobierane przez zapytanie, używając indeksów i partycjonując duże tabele. Chociaż nie jest to coś, co większość ludzi będzie potrzebować (lub będzie w stanie) zrobić, jest to istotna kwestia, o której należy pamiętać podczas projektowania zapytań do bazy danych od podstaw.

Na przykład, jeśli zapytanie do bazy danych wyszukuje dane o użytkowniku w celu zalogowania, zapytanie powinno mieć LIMIT 1, ponieważ wyraźnie nie powinno być wymaganych więcej niż danych jednego użytkownika.

Uwaga: dotyczy to bardziej projektu bazy danych niż optymalizacji.Chociaż utrzymanie wydajności jest ważne, ten wysiłek jest bardziej odpowiedni dla twórców wtyczek (w kontekście WordPressa) niż dla większości użytkowników końcowych.

Pamiętaj, że przed przetestowaniem prędkości po wprowadzeniu jakichkolwiek zmian w dostępie do danych należy upewnić się, że wyłączono buforowanie zapytań, uruchamiając następujące polecenie:

SET SESSION query_cache_type=0;

3 – Korzystanie z partycjonowania danych

Dzięki partycjonowaniu danych na mniejsze części bazy danych stają się bardziej wydajne i mniej czasochłonne w zarządzaniu. Ta strategia może pomóc skrócić czas poświęcany na procesy konserwacji, takie jak tworzenie kopii zapasowych i aktualizacje, a także ograniczyć ilość danych, którymi trzeba zarządzać. Ogólnie rzecz biorąc, pomaga poprawić wydajność i zoptymalizować wykorzystanie zasobów.

Aby podzielić dane w bazie danych, możesz wykonać następujące kroki:

  1. Wybierając tabelę do partycjonowania, pamiętaj, aby wybrać taką, która zawiera dużą ilość danych i przydałaby się jej podział. Pomoże to zoptymalizować system i poprawić wydajność zapytań.
  2. Wybór właściwej metody partycjonowania bazy danych ma kluczowe znaczenie. Możesz wybrać zakres, listę, hash lub partycjonowanie kluczy – w zależności od struktury danych i zapytań, które planujesz wykonać. Upewnij się, że wybierzesz ten, który najlepiej odpowiada Twoim potrzebom w zakresie zoptymalizowanej wydajności i wyników.

    1. Partycjonowanie zakresów to idealny wybór, gdy masz dane, które można podzielić na określone zakresy.Na przykład, jeśli masz tabelę z danymi z wielu lat, możesz utworzyć partycję zakresu, aby lepiej ją uporządkować. Może opierać się na dacie lub wartości liczbowej danej kolumny.
    2. Partycjonowanie listy to wydajna technika obsługi danych, które można łatwo podzielić na różne grupy według określonego parametru.Na przykład masz tabelę z informacjami o pracownikach podzielonymi na kategorie według działów; wymaga to użycia partycjonowania listy.
    3. Partycjonowanie skrótów to skuteczna strategia organizowania danych w klastry o równej wielkości na podstawie wartości skrótu określonej kolumny.Pozwala to na równomierną dystrybucję danych na wielu partycjach, co czyni go doskonałym wyborem do wydajnej dystrybucji danych.
    4. Partycjonowanie kluczy jest podobne do partycjonowania hash, ale główna różnica polega na tym, że używa określonej wartości kolumny jako podstawy do dzielenia danych na różne grupy.To sprawia, że ​​jest to idealny wybór dla zestawów danych, które można podzielić na osobne grupy na podstawie unikalnego identyfikatora lub klucza naturalnego.
  3. Tworząc partycjonowaną tabelę, możesz skutecznie podzielić oryginalną tabelę na mniejsze. Osiąga się to poprzez dodanie klauzuli partycjonowania w instrukcji CREATE TABLE, w której określa się żądaną metodę i warunki segmentacji. W ten sposób można poprawić wydajność zapytań, a także usprawnić zarządzanie danymi.
  4. Możesz szybko skopiować dane z oryginalnej tabeli do nowo podzielonej na partycje za pomocą instrukcji INSERT INTO… SELECT. Spowoduje to łatwe wypełnienie partycjonowanej tabeli wszystkimi istotnymi informacjami.
  5. Aby korzystać z partycjonowanej tabeli, należy teraz ponownie skonfigurować aplikacje. Spowoduje to zastąpienie oryginalnej tabeli i zwiększenie wydajności aplikacji.
  6. Przed uruchomieniem jakiegokolwiek testu w celu oceny potencjalnej poprawy wydajności należy najpierw wyłączyć buforowanie zapytań, uruchamiając polecenie: SET SESSION query_cache_type=0;
  7. Aby upewnić się, że partycjonowana tabela działa płynnie, ważne jest, aby uważnie obserwować jej wydajność. Jeśli zauważysz jakiekolwiek problemy, pomocne może być dostosowanie warunków partycjonowania lub przejście na inną metodę. Regularne monitorowanie partycji pomoże zmaksymalizować ich potencjał.

Ważna uwaga dotycząca aktualizacji skryptów i partycjonowanych tabel

Chociaż partycjonowanie baz danych może pozytywnie wpłynąć na wydajność, należy pamiętać o potencjalnych problemach powodowanych przez uruchamianie skryptów uaktualniania w celu zmiany schematu bazy danych. Istotne jest, aby partycjonowane tabele były brane pod uwagę podczas tworzenia skryptów tych uaktualnień. Jeśli partycjonowane tabele nie zostaną uwzględnione w skryptach aktualizacji, mogą wystąpić potencjalne problemy, które prawie na pewno spowodują nieprawidłowe działanie witryny.

Na przykład, jeśli tworzony jest skrypt w celu dodania nowej kolumny do podzielonej na partycje tabeli, może on zmienić tylko jedną partycję, tworząc niespójności i problemy w danych. Podobnie, jeśli tworzony jest skrypt uaktualniania w celu dodania indeksu do partycjonowanej tabeli, może on wygenerować indeks tylko na jednej partycji, co skutkuje mniejszą wydajnością i niespójnymi wynikami.

Aby uniknąć takich problemów, skrypty aktualizacji muszą uwzględniać partycjonowane tabele. Może to obejmować uruchamianie skryptu na każdej partycji z osobna lub poprawianie skryptów w celu pracy z partycjonowanymi tabelami. Ważne jest również przeprowadzenie dokładnych testów, aby upewnić się, że proces aktualizacji nie generuje żadnych nieoczekiwanych problemów ani utraty danych.

4 – Redis

Dla klientów Servebolt Redis to (płatny) dodatek, który może pomóc w optymalizacji zapytań.

Redis (czasami znany jako Remote Dictionary Server) to rozwiązanie typu open source, które przechowuje dane w pamięci i może być używane do buforowania, bazy danych, a nawet jako broker wiadomości. Może być zintegrowany z bazą danych w celu poprawy wydajności, działając jako skuteczny pośrednik między aplikacją a bazą danych.

Działa w celu poprawy wydajności i czasów odpowiedzi aplikacji poprzez zmniejszenie obciążenia bazy danych. Odbywa się to poprzez przechowywanie często używanych danych w Redis zamiast w bazie danych dla każdego żądania, oszczędzając w ten sposób znaczną ilość czasu.

Dzięki odpowiedniej konfiguracji wtyczki Redis może być używany z bazą danych do optymalizacji wykonywania zapytań. Gdy wymagane dane nie znajdują się w Redis, aplikacja pobierze je z bazy danych i zapisze w Redis do wykorzystania w przyszłości. Dzięki temu pobieranie danych jest znacznie szybsze i wydajniejsze.

Korzystając z tego podejścia, aplikacja może korzystać z szybkiego dostępu do pamięci Redis, a także przechowywać i uzyskiwać dostęp do danych z bazy danych w razie potrzeby.

Pamiętaj, że jeśli wdrażasz Redis po raz pierwszy, będziesz musiał wyłączyć buforowanie zapytań przed uruchomieniem jakichkolwiek testów wydajności. Aby to zrobić, użyj polecenia:

SET SESSION query_cache_type=0;

Wniosek

Ekosystem MariaDB i MySQL oferuje szeroką gamę narzędzi i metod ułatwiających wykrywanie wąskich gardeł w wykonywaniu zapytań do baz danych, co pozwala poprawić wydajność aplikacji internetowych.

Spowolnienia mogą wystąpić przez cały okres działania dowolnej aplikacji. Próba ich uniknięcia jest świetna, ale ostatecznie musisz wiedzieć, gdzie szukać, kiedy zaczynasz diagnozować problemy z wydajnością. W zależności od rozmiaru i charakteru uruchamianych baz danych jest to proces iteracyjny, który wymaga ciągłego monitorowania, rozwiązywania problemów i ciągłego doskonalenia, aby utrzymać działanie baz danych na wysokim poziomie.