Když WordPress zpomalí: jak poznat problém v databázi (a co s tím)
Stručné shrnutí: Pokud se seká hlavně administrace a objednávky, zatímco frontend běží rychle, problém bývá v databázi WordPressu. Varováním jsou SQL dotazy nad 300 ms nebo celkový čas databáze přes 500 ms – pak má smysl řešit wp_options, wp_posts a wp_postmeta. Čištění často pomůže, ale před každým zásahem vždy udělejte zálohu.
Obsah článku
- Jak poznat problém v databázi
- Co se ve WordPressu hromadí
- Měření bez pluginu
- Kdy čištění stačí
- Shared hosting vs VPS
- FAQ
Jak poznat, že problém je v databázi (a ne jinde)
Databáze je hlavním podezřelým, když se zpomalení projevuje jen u „živých“ akcí. Typicky jde o přihlášení do administrace, ukládání článků a práci s objednávkami nebo košíkem.
Naopak pokud se načítá pomalu úplně všechno (obrázky, CSS, JavaScript), hledejte problém spíš v síti, cache nebo velikosti stránky.
Typický scénář z praxe: homepage běží z cache s TTFB kolem 100 ms, ale práce s objednávkami ve WooCommerce trvá klidně 3–6 sekund. Frontend je rychlý, backend trpí. To už není náhoda.
Nejrychlejší diagnostika? Plugin Query Monitor.
Sledujte tři věci:
- počet SQL dotazů
- celkový čas databáze
- nejpomalejší dotaz
U běžného webu je 50–120 dotazů normál. Jakmile jste na 300+ nebo vidíte dotazy přes 300 ms, máte konkrétní stopu.
Dobrý indikátor jsou i chyby:
- 504 Gateway Timeout → pomalý dotaz
- prázdná stránka po update → PHP problém
- Error establishing a database connection → vyčerpaná připojení
Co se v databázi WordPressu vlastně hromadí
WordPress není jedna tabulka, je to propojený systém. Pro výkon ale nemusíte řešit všechno; v praxi se opakují stále stejné zdroje problémů.
Víte-li, kam se dívat, dokážete většinu zpomalení odhalit během pár minut.
Kam se dívat?
- wp_options: nastavení + autoload
- wp_posts: obsah (články, produkty, revize)
- wp_postmeta: metadata (největší „žrout“ u e‑shopů)
Hlavní problém jménem autoload
Řádky s autoload = yes se načítají při každém requestu. To znamená, že i relativně malý nárůst objemu dat se násobí při každém načtení stránky, a to už je čistý overhead, který nejde obejít cache.
Na testu menšího webu:
- 1,2 MB autoload → admin ~430 ms
- 9,6 MB autoload → admin ~1,7 s
Praktické pravidlo zní:
- do 5 MB = OK
- nad 5 MB = kontrola
- nad 10 MB = řešit
Kde databáze webu bobtná
Většina problémů nevzniká jedním velkým nárůstem, ale postupně. Přibývají malá data, která se nikdy nemažou.
- revize článků
- transienty (dočasná data)
- spam komentáře
- metadata (hlavně WooCommerce)
- page buildery
U WooCommerce není problém mít miliony řádků ve wp_postmeta. Rozdíl mezi rychlým a pomalým webem je v tom, jestli nad nimi běží cílené dotazy, nebo „full scan“ bez indexu.
Typické stavy z praxe
| Stav webu | Autoload | wp_posts | wp_postmeta | Příznak |
|---|---|---|---|---|
| Nový web | 0,5–1,5 MB | 50–300 | 300–2 000 | Bez problému |
| Blog (3 roky) | 1–4 MB | 2k–8k | 10k–40k | Pomalejší admin |
| WooCommerce (3 roky) | 3–12 MB | 20k–120k | 200k–1,5M | Timeouty |
| Page builder migrace | 5–20 MB | 5k–50k | 80k–600k | Pomalé editace |
Samotná velikost tabulek není problém. Problém je, když růst dat není doprovázený odpovídající strukturou (indexy, optimalizované dotazy).
Jak změřit stav databáze bez pluginu
Plugin je pohodlný, ale první audit zvládnete i bez něj. Výhodou je, že vidíte surová data bez interpretace, a tím pádem přesně víte, co řešíte.
Důležité: Než začnete, udělejte zálohu.
Velikost tabulek
Tenhle dotaz vám během pár sekund ukáže, kde je problém. Pokud jedna tabulka výrazně „utíká“, je to první kandidát na analýzu.
SELECT
table_name AS tabulka,
ROUND((data_length + index_length) / 1024 / 1024, 2) AS velikost_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 10;
Autoload
Nejde jen o velikost, ale i o počet řádků. Velké množství malých položek bývá často horší než pár velkých.
SELECT
ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb,
COUNT(*) AS pocet_radku
FROM wp_options
WHERE autoload = ‚yes‘;
Revize
Revize samy o sobě nevadí. Problém začíná ve chvíli, kdy jich jsou desítky tisíc a vstupují do dotazů.
SELECT COUNT(*) AS pocet_revizi
FROM wp_posts
WHERE post_type = ‚revision‘;
WP-CLI
WP-CLI je rychlejší a bezpečnější než ruční zásahy v adminu, hlavně u větších webů.
- wp db size –tables
- wp transient delete –expired
Z praxe: Mazání „podle pocitu“ je zaručený recept, jak web rozbít. Pokud si nejste jistí, co konkrétní data dělají, je lepší je nejdřív analyzovat než mazat.
Kdy optimalizace databáze stačí a kdy už ne
Optimalizace databáze má smysl tehdy, když řešíte objem dat, ne výkon infrastruktury. Jinými slovy: když obsahuje zbytečnosti, ne když nestíhá obsluhovat provoz.
Pomůže, pokud problém tvoří:
- transienty
- revize
- spam
- session data
- autoload do cca 10 MB
V těchto případech se často bavíme o minutách práce a okamžitém zlepšení.
Pokud ale i po vyčištění databáze vidíte dotazy nad 500 ms, problém je jinde. Typicky v neefektivním dotazu nebo limitu serveru.
Bezpečný postup pro optimalizaci databáze
- Záloha (a ověřit obnovu)
- Smazat prošlé transienty
- Omezit revize
- Vyčistit spam
- Zkontrolovat autoload
Důležité je pořadí. Bez zálohy je jakýkoliv zásah zbytečné riziko.
Limit revizí:
define(‚WP_POST_REVISIONS‘, 10);
Co nečekat od OPTIMIZE TABLE
U InnoDB nejde o „zrychlovací tlačítko“. Pomáhá hlavně po velkém mazání, jinak má efekt minimální.
Pokud výkon řeší OPTIMIZE TABLE, problém byl pravděpodobně jinde a jen se tím dočasně zamaskoval.
Shared hosting vs VPS: kdy už databáze potřebuje víc
Optimalizace má svoje limity. Databázi můžete vyčistit, zmenšit a zrychlit dotazy, ale pokud naráží na limity prostředí, další zlepšení už z ní nevytlačíte. V tu chvíli nejde o problém WordPressu, ale o kapacitu, na které běží.
Na sdíleném hostingu se o výkon dělíte. To je v pořádku, dokud web nezačne generovat vyšší zátěž. Jak přijdou kampaně, importy, více uživatelů v administraci, začnou se projevovat limity: pomalejší odezvy, čekání na připojení nebo timeouty.
Typické limity:
- počet připojení
- CPU
- diskové I/O
- RAM
Co vidíme v praxi
U WooCommerce webů rozdíl není jen ve výkonu, ale i v konzistenci. VPS zvládá zátěž bez výrazných výkyvů:
- shared hosting → práce s objednávkami 5–9 s
- VPS → 1–3 s
Pro VPS zvolte kvalitního poskytovatele, u kterého máte jistotu, že váš web neuloží na staré železo. Například u Webglobe najdete 3 dobře optimalizované balíčky a také managed VPS pro ty, kdo se nastavením a správou serveru nechtějí zabývat.
Kdy zvažovat upgrade na VPS
| Situace | Optimalizace | VPS |
|---|---|---|
| Firemní web | Ano | Jen při špičkách |
| Blog | Ano | Při timeoutu |
| WooCommerce do 500 objednávek | Často ano | Někdy |
| WooCommerce 2000+ | Jen údržba | Ano |
| Časté importy | Ne | Ano |
| Page builder heavy web | Někdy | Často |
Více se tématu věnujeme v článku Jak poznat, že je čas přejít na VPS.
Klíčová věc: VPS není náhrada za špatný dotaz. Pokud plugin dělá neefektivní SQL nad miliony řádků, silnější server problém jen oddálí. Správný postup je vždy změřit → vyčistit → analyzovat → až pak řešit hosting.
Další užitečné články:
- Jak PHP, databáze a web server ovlivňují rychlost načítání stránek
- Jak WordPress a další webové aplikace ovlivňují rychlost načítání webových stránek
- Pomalé načítání webových stránek: Zjistěte, kde je problém a vyřešte ho
- Jak hardware ovlivňuje výkon webhostingu
Časté otázky o databázi WordPressu
Jak velká databáze je ještě v pořádku?
Velikost je jen orientační metrika. V praxi rozhoduje:
- autoload (wp_options)
- struktura wp_postmeta
- rychlost SQL dotazů
Malá databáze může být pomalá, velká může být rychlá.
Stačí běžná záloha?
Ano, ale jen pokud ji umíte obnovit. V praxi se často ukáže, že záloha existuje, ale její obnova trvá hodiny. Proto doporučujeme před čištěním samostatný SQL export.
Je lepší MariaDB nebo MySQL?
Rozdíl existuje, ale většinou není klíčový.
Výkon víc ovlivňuje:
- kvalita dotazů
- indexy
- konfigurace
- hosting
Jinými slovy: špatný dotaz nezachrání ani lepší databáze.
Jak často databázi čistit?
- firemní web → 1× za 6 měsíců
- blog → 1× za 3 měsíce
- e‑shop → po kampaních nebo importech
Automatické čištění bez kontroly může nadělat víc škody než užitku.
