Nejprve profilujte pomalou stránku nebo administrativní akci a zjistěte konkrétní dotaz. Zkontrolujte růst tabulek, autoloadované options, naplánované úlohy a data odstraněných pluginů. Mazání a indexy zkoušejte na stagingu se zálohou; po změně ověřte funkce, logy a měření, nejen velikost databáze.
Optimalizace databáze WordPressu nemá začínat tlačítkem „vyčistit vše“. Databáze uchovává obsah, nastavení, uživatele, vztahy i data pluginů. Velká tabulka nemusí být pomalá a malá tabulka může mít chybný dotaz bez indexu. Mechanické mazání revizí nebo transients proto často přinese malý efekt, zatímco neznámý záznam objednávky či fronty může být nenahraditelný.
Správný postup změří konkrétní pomalý požadavek, identifikuje dotazy a teprve poté rozhodne o zásahu na úrovni dat, aplikace nebo serveru. Každá změna se zkouší na kopii s reálným objemem dat a s obnovitelnou zálohou. Článek vysvětluje nejčastější oblasti databáze WordPressu bez univerzálních příkazů, které by mohly poškodit odlišnou instalaci.
Změřte problém na konkrétním požadavku
Rozlište pomalou veřejnou stránku, vyhledávání, uložení článku, seznam objednávek nebo naplánovanou úlohu. Každá cesta používá jiné tabulky. Profilovací nástroj nebo databázový slow query log ukáže čas, počet volání a opakování. Stejný dotaz provedený stokrát může být větší problém než jeden mírně pomalý dotaz.
Měřte s reprezentativním uživatelem, parametry a stavem cache. Zaznamenejte verzi kódu, velikost dat a čas před zásahem. Nevypínejte indexy ani nespouštějte náročnou analýzu v ostré špičce bez plánu. Pokud pomalost způsobuje externí API nebo výpočet v PHP, čištění databáze jen odvede pozornost.
Inventarizujte tabulky a jejich vlastníky
Získejte seznam tabulek, velikost dat a indexů, počet řádků a tempo růstu. Prefix pomůže odhadnout původ, ale není důkazem, že tabulku lze smazat. Dohledejte plugin, vlastní kód nebo integrační proces, který ji používá. U multisite zohledněte síťové i webové tabulky. Neznámou tabulku nejprve archivujte a otestujte.
Velké logovací nebo frontové tabulky mohou mít nastavenou nevhodnou retenci nebo selhávající zpracování. Řešením je opravit zdroj růstu a zavést bezpečný životní cyklus, nikoli pravidelně ručně mazat symptom. Objednávková, členská a formulářová data mohou podléhat provozním či právním požadavkům, které musí potvrdit jejich vlastník.
- Velikost a tempo růstu
- Plugin nebo proces vlastnící tabulku
- Retenční pravidlo a účel
- Postup obnovy před odstraněním
Zkontrolujte options a autoload
Automaticky načítané (autoload) options se načítají při mnoha požadavcích. Problém vzniká, když plugin uloží velký objekt nebo rostoucí log jako automaticky načítané nastavení. Seřaďte hodnoty podle velikosti, identifikujte vlastníka a ověřte, zda jsou skutečně potřeba při každém načtení. Hodnotu neupravujte ručně, aniž byste rozuměli serializaci a očekávanému formátu.
Odstraněné pluginy mohou zanechat options, ale název podobný starému pluginu může stále používat jiná část. Změnu nejprve vyzkoušejte na stagingu a sledujte administraci i front-end. Velkou aktivní konfiguraci lze přesunout, rozdělit nebo načítat na vyžádání úpravou kódu. Samotné vypnutí autoloadu může snížit jednu zátěž a zvýšit počet samostatných dotazů.
Revize, transients a metadata čistěte podle pravidla
Revize chrání redakční práci a umožňují návrat, proto jejich počet nastavte podle četnosti úprav a potřeb auditu. Hromadné odstranění všech verzí může tým připravit o užitečnou historii. Transients jsou dočasné cache hodnoty, ne každý plugin však korektně odstraňuje expirované záznamy. Nejprve zjistěte, zda jejich nárůst nesouvisí s chybou plánovaných úloh.
Metadata příspěvků a uživatelů mohou zůstat po smazání objektu nebo po změně pluginu. Identifikujte osiřelé záznamy bezpečným dotazem na kopii a ověřte vzorek. U WooCommerce nebo vlastních datových vrstev nepoužívejte obecný čistič bez potvrzené kompatibility. Po odstranění optimalizujte tabulku jen tehdy, když je přínos relevantní a údržbové okno snese potřebné uzamčení.
- Retence revizí podle redakce
- Expirovaná data v cache podle vlastníka
- Osiřelé záznamy ověřené na vzorku
- Žádné plošné mazání neznámých meta klíčů
O indexech a změnách schématu ať rozhodují důkazy
Chybějící index může zpomalovat filtrování velké tabulky, nadbytečný index zase zpomaluje zápisy a zabírá místo. Návrh vychází z plánu konkrétního dotazu, selektivity a skutečného objemu. Před přidáním zkontrolujte existující indexy a kompatibilitu s budoucími migracemi pluginu. Vlastní index v cizí tabulce zdokumentujte, protože aktualizace jej nemusí znát.
Změnu schématu nasazujte kontrolovaně s odhadem času, zálohou a možností návratu. Po zásahu zopakujte stejný profil, porovnejte čas a zkontrolujte zápisy, importy, editor i zálohování. Sledujte další růst, aby se problém nevrátil. Nejlepším výsledkem je odstraněná kořenová příčina a měřitelně rychlejší scénář, nikoli jen nižší počet megabajtů.
Časté dotazy
Je bezpečné smazat všechny revize WordPressu?
Ne bez posouzení redakční potřeby a zálohy. Revize umožňují návrat ke staršímu obsahu. Vhodnější je nastavit přiměřenou retenci a starší záznamy po testu kontrolovaně čistit.
Zrychlí menší databáze automaticky web?
Ne. Výkon závisí na konkrétních dotazech, indexech, cache, serveru a aplikačním kódu. Smazání dat, která se při požadavku nepoužívají, nemusí přinést měřitelnou změnu. Nejprve profilujte scénář.
Mohu použít plugin na čištění databáze?
Může pomoci u známých bezpečných kategorií, ale automatické označení není zárukou. Zkontrolujte kompatibilitu, vlastníka dat, vytvořte zálohu a výsledek nejprve ověřte na stagingu s reálnými funkcemi.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
