Strojenie wydajności MySQL

Ta strona jest oryginalną dokumentacją PmaControl. Zachowuje praktyczną strukturę indeksu do pracy nad optymalizacją MySQL, bez kopiowania treści zewnętrznych i bez zależności od zewnętrznego produktu.

Cel

Strojenie MySQL zmniejsza latencję, stabilizuje przepustowość i zapobiega powtarzającym się saturacjom. Praca musi zaczynać się od realnych pomiarów, a nie od ogólnych wartości kopiowanych między serwerami.

Zalecana kolejność pracy

1. Zbierz realne obciążenie: QPS, latencję, błędy, połączenia, I/O dysku, pamięć i CPU.
2. Wskaż dominujące zapytania przez performance_schema, slow log albo narzędzie digest.
3. Sprawdź schemat: brakujące indeksy, indeksy nadmiarowe, zbyt szerokie typy i tabele bez klucza głównego.
4. Dostosuj InnoDB: buffer pool, redo log, flush, wątki I/O i strategię trwałości.
5. Przejrzyj limity serwera: połączenia, otwarte pliki, cache tabel i rozmiary tabel tymczasowych.
6. Testuj w kontrolowanym oknie, z opisanym rollbackiem.

Przydatne komendy

SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Questions';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

Najważniejsze

Dobre strojenie MySQL jest inkrementalne. Zmienna zmieniona bez pomiaru przed i po staje się długiem operacyjnym.

Zbuduj porównywalny punkt odniesienia

Zapisz dokładną wersję serwera, zasoby hosta, wielkość danych, wersję aplikacji, profil ruchu i okres obserwacji. Oddziel czas odpowiedzi klienta od czasu wykonania SQL: kolejka puli połączeń, komunikacja sieciowa i praca aplikacji mogą dominować nawet przy szybkich zapytaniach. Przed zmianą i po niej zachowaj ten sam profil obciążenia i współbieżność.

SELECT VERSION() AS server_version, @@version_comment AS distribution;
SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Uptime', 'Questions', 'Threads_connected', 'Threads_running',
  'Innodb_buffer_pool_read_requests', 'Innodb_buffer_pool_reads',
  'Innodb_log_waits', 'Created_tmp_tables', 'Created_tmp_disk_tables'
);

Pobierz dwa zestawy liczników w reprezentatywnym odstępie. Questions jest licznikiem narastającym: tempo instrukcji klienta = ΔQuestions / czas w sekundach, a nie wartość licznika. Restart lub wyzerowanie unieważnia okres. Zapisz opóźnienia p50, p95 i p99, ukończoną pracę oraz błędy; niższa średnia może ukrywać pogorszenie najwolniejszych odpowiedzi.

Znajdź zapytania zużywające zasoby

SELECT SCHEMA_NAME, LEFT(DIGEST_TEXT, 140) AS digest,
       COUNT_STAR AS executions,
       ROUND(SUM_TIMER_WAIT / 1000000000000, 3) AS total_seconds,
       ROUND(AVG_TIMER_WAIT / 1000000000, 3) AS average_ms,
       SUM_ROWS_EXAMINED, SUM_ROWS_SENT
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST IS NOT NULL
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

To zapytanie MySQL Performance Schema porządkuje skumulowany czas wykonania, a nie p95 z ostatniego okna. Czasy są w pikosekundach. Sprawdź instrumentację i historię resetów; pusty wynik nie dowodzi braku ruchu. Częste krótkie zapytania mogą kosztować więcej niż jedno wolne. Porównaj wiersze przejrzane ze zwróconymi, a następnie użyj EXPLAIN FORMAT=JSON z typowymi parametrami. EXPLAIN ANALYZE wykonuje instrukcję: wymaga kontrolowanego środowiska i obsługiwanej wersji.

Dobierz zmianę do wąskiego gardła

Weryfikuj pojedynczą zmianę

Zapisz hipotezę, poprzednią wartość lub schemat, oczekiwany efekt i warunek wycofania. Rozgrzewaj pamięci podręczne tak samo, powtarzaj reprezentatywne próby i zachowuj wyniki surowe. Porównuj razem opóźnienia, przepustowość, błędy, CPU, pamięć, I/O i opóźnienie replikacji. Odrzuć przyspieszenie kosztem poprawności, trwałości lub innego ważnego obciążenia. Sprawdź wynik w szczycie i w pełnym cyklu biznesowym.

Dalsza diagnostyka

• Kontrola stanu ustala dostępność i pojemność.
• Kontrola schematu i parametry wydajności opisują konkretne zmiany.

Oficjalne źródła

• MySQL Performance Schema
• MySQL EXPLAIN