Wysokie użycie CPU w MySQL: diagnoza krok po kroku

Objawy pojawiają się razem: strona zwalnia do żółwiego tempa, top pokazuje mysqld lub mariadbd na czele listy, a czasem aplikacja zgłasza "Too many connections". Niezależnie od tego, czy to wysokie użycie CPU w MySQL, czy wysokie CPU w MariaDB, przyczyną rzadko jest zbyt mały serwer. O wiele częściej garstka zapytań wykonuje znacznie więcej pracy, niż powinna, a cała reszta ustawia się za nimi w kolejce. Ten poradnik przeprowadza przez diagnozę na obecnych wydaniach, takich jak MySQL 8.4 i MariaDB 11, od pierwszego spojrzenia na żywo po trwałą poprawkę.

Krok 1: zobacz, co stoi za wysokim użyciem CPU w MySQL teraz

Połącz się klientem wiersza poleceń (w MariaDB nazywa się mariadb) i uruchom SHOW FULL PROCESSLIST. Każdy wiersz to połączenie: jak długo trwa jego bieżąca instrukcja, jej stan i pełny tekst zapytania. Wzorce szybko rzucają się w oczy:

• Dziesiątki kopii tego samego zapytania, z których każda trwa kilka sekund: jedno kosztowne zapytanie, w które uderza normalny ruch.
• Wiele połączeń w stanie Sleep: aplikacja otwiera połączenia i ich nie zamyka albo jej pula jest za duża.
• Stany takie jak "Waiting for table metadata lock": zmiana schematu lub długa transakcja blokuje wszystkich pozostałych.
• Stany sortowania i tabel tymczasowych na wielu wierszach: grupowanie lub porządkowanie bez odpowiedniego indeksu.

Dwa liczniki statusu dopełniają obrazu. Threads_running pokazuje, ile zapytań wykonuje się w tej chwili, a Max_used_connections szczyt od ostatniego restartu. Serwer z kilkoma rdzeniami CPU i dziesiątkami uruchomionych wątków jest przeciążony zapytaniami, a nie odwiedzającymi.

Krok 2: włącz log wolnych zapytań MySQL

Migawka na żywo pokazuje kryzys; log wolnych zapytań MySQL pokazuje wzorzec. Włącz go, ustawiając slow_query_log na ON, z long_query_time około jednej sekundy na początek, a potem obniż próg, gdy najgorsi winowajcy zostaną naprawieni. Oba można zmienić w czasie działania i utrwalić w pliku konfiguracyjnym serwera. MariaDB używa tych samych nazw zmiennych i wyjaśnia opcje w swoim przeglądzie logu wolnych zapytań.

Zostaw log włączony na kilka reprezentatywnych, obciążonych dni, a potem go podsumuj. mysqldumpslow, albo mariadb-dumpslow w MariaDB, grupuje podobne instrukcje, a pt-query-digest z Percona Toolkit daje bardziej szczegółowy ranking. Sortuj według łącznego czasu, a nie według pojedynczego najwolniejszego zapytania: instrukcja, która trwa 0.2 sekundy, ale wykonuje się przy każdym wyświetleniu strony, kosztuje znacznie więcej niż nocny raport.

Krok 3: napraw zapytania, które mają znaczenie

Dla każdego zapytania ze szczytu listy uruchom EXPLAIN i przeczytaj, co optymalizator planuje zrobić. Zwykła naprawa wolnych zapytań to jedno z tych:

• Brakujący lub nieodpowiedni indeks. Pełny skan tabeli, widoczny jako type ALL, na dużej tabeli, gdzie indeks złożony na filtrowanych i sortowanych kolumnach znalazłby wiersze bezpośrednio.
• Funkcja na kolumnie indeksowanej, na przykład opakowanie kolumny z czasem w funkcję daty wewnątrz klauzuli WHERE, co uniemożliwia użycie indeksu. Naprawia to przepisanie warunku jako zakresu.
• Wiodące symbole wieloznaczne w wyszukiwaniach LIKE, którym nie pomoże żaden zwykły indeks. Prawdziwą poprawką jest indeks pełnotekstowy lub usługa wyszukiwania.
• To samo małe zapytanie powtarzane setki razy na stronę, typowe dla wtyczek i pętli aplikacji, lepiej rozwiązać cache w aplikacji.

Zmiany indeksów najpierw przetestuj na kopii bazy danych. Każdy indeks przyspiesza jakieś odczyty, ale dodaje pracy przy każdym insercie i update, a budowa indeksu na bardzo dużej tabeli może ją spowalniać na czas budowania.

Dlaczego "Too many connections" jest zwykle objawem

Błąd oznacza, że wszystkie dozwolone połączenia są w użyciu. Domyślne max_connections zarówno w MySQL, jak i MariaDB to 151, i jego podniesienie kusi. Każde połączenie potrzebuje jednak pamięci, a więcej jednoczesnych zapytań na tych samych rdzeniach CPU tylko spowalnia każde z nich. Szukaj raczej przyczyny zbyt wielu połączeń:

• Wolne zapytania trzymające połączenia otwarte, co prowadzi z powrotem do kroku 3.
• Więcej procesów PHP-FPM lub wątków aplikacji, niż baza może obsłużyć naraz. Warstwę WWW należy dobrać tak, by jej szczyt mieścił się w max_connections, z zapasem na administrację.
• Bezczynne połączenia utrzymywane godzinami przez połączenia trwałe lub zbyt dużą pulę, kontrolowane przez wait_timeout i ustawienia puli aplikacji.

Kontrola konfiguracji i strojenie wydajności MariaDB

Gdy zapytania są pod kontrolą, sprawdź ustawienia, które decydują, jak mocno serwer bazy danych musi pracować. Pula buforów InnoDB powinna pomieścić dane używane regularnie, aby odczyty szły z pamięci, a nie z dysku. Tabele tymczasowe zrzucane na dysk widać w liczniku Created_tmp_disk_tables. Te kontrole są rdzeniem przeglądu wydajności MySQL i MariaDB. Cache zapytań nie jest rozwiązaniem: MySQL 8 go usunął, a MariaDB dostarcza go wyłączony, bo na obciążonych serwerach staje się punktem rywalizacji. Przy strojeniu wydajności MariaDB na serwerach z wieloma krótkimi połączeniami warto spojrzeć na pulę wątków. A jeśli nadal używasz MySQL 8.0, pamiętaj, że Oracle zakończył jego wsparcie w kwietniu 2026 r.; 8.4 to wydanie długoterminowe, na które przechodzi większość serwerów 8.0, a aktualizacja to dobry moment na ponowne sprawdzenie planów zapytań.

Najczęściej zadawane pytania: wysokie użycie CPU w MySQL

Czy wysokie CPU to zawsze problem bazy danych?

Nie. Jeśli mysqld lub mariadbd nie jest blisko szczytu listy procesów, zajrzyj zamiast tego do PHP, serwera WWW lub zadania kopii zapasowej. Baza danych jest prawdopodobnym winowajcą, gdy jej proces dominuje, a lista procesów pokazuje piętrzące się zapytania.

Czy restartować MySQL, gdy CPU jest na maksimum?

Restart na chwilę czyści kolejkę, ale te same zapytania wracają z ruchem, a restart opróżnia też pulę buforów, więc serwer jest wolniejszy, dopóki się nie rozgrzeje. Najpierw zapisz wynik SHOW FULL PROCESSLIST, żeby nie stracić dowodów.

Czy bezpiecznie zabić długo działające zapytanie?

KILL QUERY z identyfikatorem połączenia z listy procesów zatrzymuje instrukcję i zostawia połączenie otwarte, a KILL kończy połączenie. Zatrzymanie dużego zapisu może chwilę potrwać, bo jego zmiany są wycofywane, i nie usuwa przyczyny, więc zanotuj zapytanie, zanim je zabijesz.

Jeśli baza danych w Los Angeles lub gdziekolwiek indziej wciąż się przegrzewa, nasza usługa optymalizacji baz danych MySQL i MariaDB przegląda log wolnych zapytań, indeksy i konfigurację, a większość upływającego czasu idzie na zebranie logu wolnych zapytań z kilku obciążonych dni, a nie na same zmiany. Gdy drugą połową problemu jest serwer WWW, zobacz naszą usługę optymalizacji serwera WWW Apache. Skontaktuj się z nami, podając wersję bazy danych i opis tego, kiedy zdarzają się spowolnienia.