Przy wyborze hostingu nie wystarczy sprawdzić, ile baz MySQL można utworzyć. Liczba baz mówi o organizacji konta, ale niewiele o tym, jak szybko będą wykonywane zapytania. Na działanie aplikacji wpływają również limity połączeń, zasoby serwera bazodanowego, sposób rozliczania CPU i I/O oraz jakość samych zapytań.
Dlatego przy wolnym WordPressie albo WooCommerce trzeba rozdzielić dwa pytania: czy baza jest ograniczana przez hosting oraz czy aplikacja wykonuje zbyt ciężkie lub zbyt liczne zapytania. Te problemy mogą wyglądać podobnie, ale wymagają innych działań.
Liczba baz MySQL nie mówi, jak szybka będzie baza
Pakiet może pozwalać utworzyć 10, 50 albo nielimitowaną liczbę baz, a mimo to wszystkie mogą korzystać z tej samej infrastruktury i tych samych ograniczeń konta. Sam limit liczby baz jest więc parametrem organizacyjnym.
Jeżeli utrzymujesz kilka WordPressów, osobna baza dla każdej strony ułatwia zarządzanie i migrację, ale nie oznacza automatycznie osobnego CPU, RAM ani osobnego przydziału operacji dyskowych.
Przed zakupem sprawdź, czy operator podaje ograniczenia dotyczące połączeń, czasu zapytań, zasobów bazy albo osobnego mechanizmu kontroli obciążenia MySQL.
Jakie limity bazy mogą mieć znaczenie?
| Parametr | Co może ograniczać |
|---|---|
| Liczba połączeń | Ile równoczesnych połączeń aplikacja może utrzymać z bazą |
| CPU bazy | Ile czasu procesora mogą zużywać zapytania danego konta lub użytkownika |
| I/O bazy | Ilość lub przepustowość danych odczytywanych i zapisywanych przez warstwę MySQL, jeśli operator stosuje taki limit |
| Czas wykonania / timeouty | Czy operator ogranicza czas wykonywania zapytań lub procesów bazodanowych i na jakich zasadach |
| Pamięć | Jak duże bufory lub operacje mogą być dostępne w danym środowisku |
| Rozmiar bazy | Ile danych można przechowywać, ale nie określa bezpośrednio szybkości |
Nie każdy hosting publikuje wszystkie te wartości. Brak liczby w tabeli oferty nie oznacza automatycznie braku ograniczenia — warto wtedy zapytać operatora, w jaki sposób kontrolowane jest obciążenie bazy.
Połączenia do MySQL — kiedy limit zaczyna mieć znaczenie?
Aplikacja może otwierać połączenia do bazy podczas obsługi żądań. Przy większej liczbie równoległych użytkowników, wielu procesach PHP albo zadaniach w tle liczba aktywnych połączeń może wzrosnąć.
Jeżeli hosting ogranicza liczbę połączeń i aplikacja dochodzi do tego limitu, nowe operacje mogą czekać albo kończyć się błędem. Przy hostingu współdzielonym warto ustalić, czy ograniczenie dotyczy Twojego użytkownika lub konta MySQL, czy jest wyłącznie globalnym limitem całego serwera. Sam wzrost limitu nie naprawi jednak aplikacji, która otwiera połączenia niepotrzebnie lub wykonuje bardzo wolne zapytania. Błąd połączenia WordPressa z bazą wymaga wtedy sprawdzenia danych z czasu awarii, a nie samego komunikatu. Jeżeli rosnące tabele są częścią problemu, zobacz jak ustalić, co powiększa bazę WordPressa.
Warto więc odróżnić:
- brak dostępnego połączenia,
- długie wykonanie istniejącego zapytania,
- brak dostępnego procesu PHP,
- przeciążenie CPU lub I/O.
Przykład potwierdzonego parametru: zapisane limity połączeń MySQL per user dla planów hitme.pl wynoszą: Studencki 20, Start 20, Mała Firma 30, E-Biznes 50 i Duża Firma 70. Sprawdź aktualne warunki tych planów (link partnerski).
Wolne zapytanie a wolna baza — to nie to samo
Pojedyncze źle napisane zapytanie może być wolne nawet na szybkim serwerze. Może skanować bardzo dużo rekordów, wykonywać kosztowne sortowanie albo korzystać z kolumn bez odpowiednich indeksów.
Z drugiej strony poprawne zapytania mogą zwalniać, jeśli serwer bazy jest przeciążony lub hosting ogranicza zasoby.
Dlatego informacja „baza działa wolno” jest zbyt ogólna. Potrzebujesz konkretu: które zapytanie jest wolne, kiedy to się dzieje i czy w tym samym czasie rosną limity CPU, I/O albo kolejki procesów.
Czy duża baza oznacza wolnego WordPressa?
Nie automatycznie. Sama wielkość bazy nie mówi, czy zapytania są szybkie. Baza o kilku gigabajtach może działać poprawnie, jeśli zapytania korzystają z odpowiednich indeksów i nie skanują zbędnych danych. Z kolei niewielka baza może być wolna przez źle napisane zapytania lub rozrośnięte tabele używane przy każdym wejściu.
W WordPressie znaczenie ma nie tylko liczba rekordów, ale też to, które tabele są odpytywane najczęściej, jakie opcje są ładowane automatycznie oraz jak działają wtyczki.
Nie wybieraj więc hostingu wyłącznie na podstawie deklarowanego maksymalnego rozmiaru bazy.
MySQL Governor — co to zmienia?
Niektórzy operatorzy korzystający z CloudLinux stosują MySQL Governor, który pozwala monitorować i ograniczać wykorzystanie zasobów przez użytkowników MySQL. Może uwzględniać m.in. CPU i I/O generowane przez zapytania. To odrębna warstwa kontroli zasobów bazy, niezależna od samych limitów LVE dla procesów użytkownika.
Nie należy jednak zakładać, że każdy hosting z CloudLinux używa MySQL Governor ani że ma identyczną konfigurację. Jeżeli operator go stosuje, zapytaj, jakie parametry są monitorowane i czy użytkownik może zobaczyć historię przekroczeń.
CPU i I/O bazy a limity konta
Obciążenie MySQL nie zawsze jest raportowane dokładnie tak samo jak CPU i I/O procesów PHP. Zależy to od architektury hostingu, konfiguracji serwera bazodanowego i użytych narzędzi kontroli zasobów.
Dlatego wysoki czas odpowiedzi bazy nie musi pokrywać się 1:1 z wykresem CPU konta. Analogicznie spadek liczby zapytań nie musi automatycznie dać identycznego spadku I/O widocznego w panelu.
Przy analizie nie próbuj więc wyciągać wniosków z jednego wykresu. Zestawiaj czas problemu z danymi o CPU, PMEM, I/O, IOPS oraz — jeśli operator je udostępnia — osobnymi statystykami MySQL.
Redis i object cache a baza danych
Persistent object cache może ograniczyć część powtarzanych odczytów z bazy, ale nie naprawia ciężkich zapytań, które nadal muszą być wykonywane, ani problemów wynikających z błędnej struktury danych.
Redis jest więc jednym ze sposobów ograniczenia części pracy aplikacji, a nie zamiennikiem diagnostyki MySQL.
Różnicę opisuje szerzej poradnik o Redis i persistent object cache.
PHP workers a połączenia do bazy
Więcej PHP workers może oznaczać więcej równoległych żądań aplikacji, a tym samym większą liczbę jednoczesnych operacji na bazie. Dlatego zwiększenie limitu workers bez sprawdzenia możliwości MySQL nie zawsze poprawia sytuację.
Jeżeli aplikacja generuje długie zapytania, większa współbieżność może wręcz zwiększyć presję na bazę.
Więcej o tej zależności znajdziesz w poradniku o PHP workers.
Co sprawdzić, gdy WordPress zwalnia przez bazę?
Zbierz konkretny przypadek zamiast ogólnego „MySQL jest wolny”. Przydatne są:
- dokładna godzina problemu,
- adres lub operacja, która była wolna,
- informacja, czy problem dotyczył całej strony czy jednej funkcji,
- czas wykonania najwolniejszych zapytań, jeśli masz do niego dostęp,
- wykorzystanie CPU, PMEM, I/O i IOPS w tym samym czasie,
- informacja, czy problem pojawia się stale czy tylko okresowo.
Jeżeli nie masz dostępu do profilerów ani slow query logu, poproś operatora lub administratora o sprawdzenie konkretnego przedziału czasu. Nie diagnozuj wyłącznie na podstawie rozmiaru bazy.
Szerszą procedurę znajdziesz w poradniku o wolnym WordPressie.
Co sprawdzić w ofercie hostingu przed zakupem?
- ile baz można utworzyć,
- czy obowiązuje limit wielkości pojedynczej bazy,
- czy istnieje limit równoczesnych połączeń,
- czy operator stosuje osobne limity CPU/I/O dla MySQL,
- czy wykorzystuje MySQL Governor lub podobny mechanizm,
- czy użytkownik może zobaczyć błędy, przekroczenia lub historię obciążenia bazy,
- czy dostępny jest slow query log albo inny sposób wskazania wolnych zapytań,
- czy support pomaga rozróżnić problem aplikacji od limitu infrastruktury.
Samo „MySQL: bez limitu” nie odpowiada na większość tych pytań.
Gotowe pytanie do operatora
Proszę podać, jakie limity dotyczą MySQL w tym pakiecie: liczba i rozmiar baz, jaki limit równoczesnych połączeń obowiązuje dla mojego użytkownika lub konta MySQL oraz ewentualne limity CPU/I/O dla użytkownika bazy. Czy stosują Państwo MySQL Governor lub podobny mechanizm? Czy po zakupie będę widzieć przekroczenia lub historię wykorzystania oraz czy możliwe jest sprawdzenie wolnych zapytań dla konkretnego przedziału czasu?
Kiedy problem leży po stronie hostingu, a kiedy aplikacji?
Hosting jest bardziej prawdopodobnym źródłem problemu, gdy spowolnienia pokrywają się z przekroczeniami limitów, kolejkami lub przeciążeniem infrastruktury. Aplikacja jest bardziej podejrzana, gdy jedno konkretne zapytanie pozostaje wolne niezależnie od ogólnego obciążenia serwera.
W praktyce oba problemy mogą występować jednocześnie. Ciężkie zapytanie zużywa dużo zasobów, a niski limit sprawia, że jego skutki pojawiają się szybciej.
Dlatego przy wyborze hostingu patrz na bazę jako osobną warstwę systemu, a nie tylko na pozycję „liczba baz MySQL” w tabeli parametrów.