A weboldal lassulásánál a legtöbben a képekre és a bővítmények számára gondolnak, pedig a háttérben gyakran az adatbázis az, ami évek alatt észrevétlenül megtelik. Egy hároméves, hetente frissülő céges oldal adatbázisa simán eléri a több száz megabájtot, egy webshopé a több gigabájtot, miközben a tényleges tartalom (a bejegyzések, oldalak, termékek szövege) ennek töredéke. A többi felhalmozódás: revíziók, félbehagyott automatikus mentések, lomtárban felejtett tartalom, lejárt átmeneti adatok, naplók és olyan táblák, amelyek gazdája már rég nincs a rendszerben. Nézzük meg, hogyan méred fel a helyzetet, mi törölhető kockázat nélkül, mihez ne nyúlj, és hogyan előzöd meg, hogy fél év múlva ugyanitt tarts.
Mitől nő évek alatt gigabájtosra egy WordPress-adatbázis?
Rövid válasz: nem a tartalomtól, hanem a tartalom körüli automatikus mellékterméktől. A WordPress alapból mindent megőriz, és nagyon kevés dolgot dob el magától.
A leggyakoribb duzzasztó tényezők:
- Bejegyzésrevíziók. Minden mentéssel új sor keletkezik a
wp_poststáblában, a bejegyzés teljes szövegével. Egy sokat szerkesztett, hosszú oldalnál 60 to 100 revízió is összejöhet. (Hivatalosan igazolt: a revíziókezelés a WordPress alapfunkciója, a dokumentáció is így írja le.) - Automatikus mentések. A szerkesztő alapértelmezés szerint percenként ment, ez külön
autosavetípusú sorokat hoz létre. - Oldalépítők metaadatai. Ez a leginkább alábecsült tétel. Az oldalépítővel készült tartalom szerkezete a
wp_postmetatáblában él, és minden revízióhoz odamásolódik. Egy 300 kilobájtos elrendezés 80 revízióval nagyjából 24 megabájt egyetlen oldalból. (Saját tapasztalat: nagyra hízott adatbázisoknál nálam ez a leggyakoribb egyszeri főtétel.) - Lomtár. A törölt bejegyzés, oldal, termék és hozzászólás nem tűnik el, csak státuszt vált.
- Spam-hozzászólások. A
wp_commentsés a hozzá tartozówp_commentmetaa spamszűrő adataival együtt hízik. - Lejárt átmeneti adatok (transient). Ezek gyorsítótár-jellegű sorok a
wp_optionstáblában. Ha nincs objektum-gyorsítótár, adatbázisba kerülnek, és a lejárat nem jelent automatikus törlést: a WordPress általában csak akkor takarítja el őket, amikor újra kéri ugyanazt a kulcsot. - Naplózó bővítmények táblái. Biztonsági bővítmények forgalmi naplói, statisztikai modulok, hibanaplók, e-mail-naplók, átirányításkezelők 404-es gyűjtői. Ezek saját táblát hoznak létre, és sok esetben korlátlanul gyűjtenek.
- Eltávolított bővítmények maradékai. A bővítmény törlése a fájlokat viszi el, az adatbázist jellemzően nem. Marad a saját tábla, maradnak a beállítássorok és a bejegyzésekhez rendelt metaadatok. (Hivatalosan igazolt: a WordPress csak az uninstall rutinnal rendelkező bővítményeknél takarít, és azt is csak akkor, ha a bővítményt szabályosan törlöd, nem pusztán kikapcsolod.)
Hogyan mérd fel, hogy melyik tábla mekkora?
Rövid válasz: táblánkénti mérettel és sorszámmal, mielőtt bármit törölnél. A vaktában futtatott takarító bővítmény olyan, mint fényképezés nélkül nekiállni a költözésnek.
A leggyorsabb út egy SQL-lekérdezés phpMyAdminban vagy Adminerben:
SELECT table_name, ROUND((data_length + index_length)/1024/1024, 1) AS meret_mb, table_rows FROM information_schema.tables WHERE table_schema = DATABASE() ORDER BY (data_length + index_length) DESC;
Ez sorba rendezi a táblákat méret szerint. WP-CLI-vel egy sor is elég: wp db size --tables --human-readable.
Ha megvan a nagy tábla, nézd meg a tartalmát is. Néhány hasznos ellenőrzés:
- Revíziók száma:
SELECT post_type, COUNT(*) FROM wp_posts GROUP BY post_type;Ha arevisionsor tízszerese apostéspagesoroknak, megvan az egyik forrás. - Átmeneti adatok:
SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '%_transient_%'; - Az automatikusan betöltődő beállítások mérete, ami a válaszidő szempontjából a legfontosabb szám:
SELECT ROUND(SUM(LENGTH(option_value))/1024, 1) AS autoload_kb FROM wp_options WHERE autoload = 'yes';Tapasztalati ökölszabály szerint 800 kilobájt fölött már érdemes utánanézni, mit hurcol be minden egyes oldalletöltés. - Árva metaadatok:
SELECT COUNT(*) FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID = pm.post_id WHERE p.ID IS NULL;
Az ismeretlen nevű táblákat ne találgasd. Keress rá a tábla előtagja utáni névre, és nézd meg, aktív-e még az a bővítmény. Ha nem találod sem az aktív, sem a kikapcsolt bővítmények között, jó eséllyel maradék.
Mi az, amit biztonságosan törölhetsz?
Rövid válasz: mindaz, ami újratermelhető vagy már senkinek nem kell. Konkrétan a következők.
Revíziók és automatikus mentések
A régi revíziók törlése nem érinti az élő tartalmat. Ésszerű megközelítés, hogy bejegyzésenként megtartod az utolsó néhányat. WP-CLI-vel: wp post delete $(wp post list --post_type=revision --format=ids) --force. Ha ezt túl nagynak tartod, célszerűbb bővítménnyel, kötegelve, korosztály szerint (például egy évnél régebbi) törölni.
Lomtár és spam
Ürítsd a lomtárat a bejegyzéseknél, oldalaknál, termékeknél és a médiánál is. A spam- és a jóváhagyásra váró, nyilvánvalóan szemét hozzászólások mehetnek. A spamszűrő saját metaadatai a hozzászólással együtt tisztulnak.
Lejárt átmeneti adatok
A lejárt transientek törlése biztonságos, mert újratermelődnek. WP-CLI-vel: wp transient delete --expired. A teljes ürítés (--all) is működik, de rövid átmeneti lassulást okozhat, amíg a gyorsítótárak újraépülnek.
Naplótáblák
A biztonsági, 404-es és e-mail-naplók régi sorai jellemzően nem hordoznak tartós értéket. Fontos sorrend: előbb a bővítmény saját beállításaiban állítsd be a megőrzési időt, és csak utána töröld a régi sorokat. Ha fordítva csinálod, a tábla hetek alatt visszanő.
Eltávolított bővítmények maradékai
Ha biztos vagy benne, hogy a bővítmény nincs használatban, az általa létrehozott tábla eldobható, a beállítássorai törölhetők. Ez az a pont, ahol a legkönnyebb hibázni, ezért ide kell a legtöbb óvatosság: mentés, majd a tábla átnevezése (RENAME TABLE) eldobás helyett, és csak egy-két hét hibátlan működés után a végleges törlés. (Szakmai feltételezés: az átnevezéses módszer sok fejlesztő gyakorlatában bevált, de a bővítmények egy része hibaüzenettel reagálhat a hiányzó táblára, ezért éles oldalon mindig figyeld a naplókat.)
Mihez ne nyúlj hozzá?
Rövid válasz: mindenhez, ami nem termelhető újra. Ezek a következők:
- Felhasználói adatok (
wp_users,wp_usermeta), akkor is, ha sok sor van bennük. - Rendelési és számlázási adatok webshopnál. A rendeléstáblák és a hozzájuk tartozó metaadatok jogszabályi megőrzési kötelezettség alá is eshetnek.
- Futásra váró ütemezett feladatok. Az Action Scheduler tábláiban a
pendingésin-progressstátuszú sorok élő munkát jelentenek. Csak a lezárt, régi sorok takaríthatók. - Licenc- és API-kulcsok a beállítások között. Ha ezeket kitörlöd, a bővítmény frissítése áll le, és a kulcs visszaszerzése sokszor több idő, mint amennyit a takarítás nyert.
- Aktív munkamenet- és kosáradatok. Ezek nagynak látszanak, de rövid életűek, és élő vásárlókat érintenek.
- Az árva metaadatok csak látszólag egyértelműek. Egyes bővítmények szándékosan tárolnak olyan sorokat, amelyekhez nem tartozik bejegyzés. Itt is a mentés utáni, ellenőrzött törlés a helyes út.
Milyen sorrendben érdemes takarítani?
Rövid válasz: mentéssel kezdesz, a legnagyobb és legbiztonságosabb tételekkel folytatod, és a végén optimalizálsz. Az alábbi sorrend éles oldalon is végigvihető:
- Teljes mentés, letöltve. Adatbázis és fájlok. Ne csak a tárhelyen legyen, hanem nálad is. Ellenőrizd, hogy a mentés mérete hihető-e.
- Felmérés. Táblaméretek, sorszámok, autoload-méret feljegyzése. Ez lesz az összehasonlítási alap.
- Válaszidő-mérés előtte. Egy admin oldal és két nyilvános oldal betöltési ideje, lehetőleg gyorsítótár nélkül.
- Lomtár és spam ürítése. Kockázat nélküli, azonnali nyereség.
- Lejárt átmeneti adatok törlése.
- Revíziók ritkítása kötegelve, néhány ezres adagokban, hogy ne fusson időtúllépésbe.
- Naplótáblák megőrzési idejének beállítása, majd a régi sorok törlése.
- Maradékok azonosítása és átnevezése (nem azonnali eldobása).
- Táblák optimalizálása. InnoDB tárolómotornál az
OPTIMIZE TABLEvalójában újraépíti a táblát, és ilyenkor adja vissza a lemezterületet. Nagy táblán ez zárolással jár, ezért alacsony forgalmú időszakban futtasd. - Utómérés és megfigyelés. Ugyanazok az oldalak, ugyanaz a módszer, és legalább egy hét figyelés.
Hogyan korlátozd a revíziók számát a jövőre nézve?
Rövid válasz: a wp-config.php néhány sorával, még az adatbázis-kapcsolatot beállító rész előtt. (Hivatalosan igazolt: ezek a konstansok a WordPress dokumentációjában szerepelnek.)
define( 'WP_POST_REVISIONS', 5 ); bejegyzésenként legfeljebb öt revíziót tart meg.
define( 'AUTOSAVE_INTERVAL', 300 ); öt percre ritkítja az automatikus mentést.
define( 'EMPTY_TRASH_DAYS', 14 ); két hét után magától üríti a lomtárat.
A revíziók teljes kikapcsolását (a nulla érték) általában nem javaslom. A revízió akkor ér a legtöbbet, amikor valaki véletlenül felülír egy jól működő szöveget, és ez sokkal gyakoribb, mint gondolnád. Az öt darab jó egyensúly a biztonság és a méret között. (Saját tapasztalat.)
Emellett érdemes megnézni a naplózó bővítmények megőrzési beállításait, és bekapcsolni egy objektum-gyorsítótárat, ha a tárhely támogatja. Ez utóbbi a transienteket kiviszi az adatbázisból, vagyis a probléma egyik forrását szünteti meg.
Mikor javít ez a válaszidőn, és mikor nem?
Rövid válasz: akkor javít, ha a lassulást tényleg az adatbázis okozta. Sok esetben nem az okozza.
Érdemi gyorsulást ott szoktam látni, ahol az automatikusan betöltődő beállítások mérete extrém, ahol a szerkesztőfelület vált vánszorgóvá a revíziók miatt, ahol a naplótábla milliós nagyságrendű és index nélkül kérdezik le, vagy ahol a megosztott tárhely adatbázis-szervere már nem fér el a memóriájában a munkakészlettel. (Saját tapasztalat.)
Nem segít viszont, ha a lassulás oka optimalizálatlan kép, hiányzó oldal-gyorsítótár, túl sok külső szkript, lassú DNS vagy gyenge tárhelycsomag. Egy 2 gigabájtos adatbázis önmagában nem baj, ha jól indexelt és a lekérdezések célzottak. A méret tünet, nem diagnózis. Ezért kell az előtte és utána mérés: enélkül a takarítás utáni jó érzés könnyen összekeverhető a tényleges javulással. Garantált gyorsulást senki nem tud ígérni, de a mérésekkel alátámasztott beavatkozás jó eséllyel megmutatja, hol van a valódi szűk keresztmetszet.
Miért nem elég az egyszeri nagytakarítás?
Itt jön a saját nézőpontom, amit érdemes külön kiemelni: a takarítás egyszeri nyereség, a valódi megoldás a felhalmozódás forrásának megszüntetése. Ha kitakarítasz egy 1,8 gigabájtos adatbázist 400 megabájtra, de nem korlátozod a revíziókat, nem állítod be a naplók megőrzését, és nem kérdezed meg magadtól, hogy melyik bővítmény termeli a sorokat, akkor egy évvel később ugyanott tartasz, ugyanazzal a kockázattal és ugyanazzal a munkával.
A gyakorlatban ez három szokást jelent. Az első: minden bővítmény-eltávolítás után rá kell nézni, hagyott-e hátra táblát vagy beállítássorokat. A második: negyedévente egy ötperces méretellenőrzés, ugyanazzal a lekérdezéssel, hogy lásd a trendet, ne csak az állapotot. A harmadik: a naplózó bővítményeknél kapcsold be a megőrzési korlátot már a telepítéskor, mert utólag mindig fájdalmasabb.
Ha csak egy dolgot viszel el ebből: mérj, mentsd le, és utána nyúlj hozzá. A törléstől nem az adatbázis fog megsérülni, hanem a mentés nélküli, kapkodó törléstől.
Források és további olvasnivalók
- WordPress Developer Resources: Editing wp-config.php (WP_POST_REVISIONS, AUTOSAVE_INTERVAL, EMPTY_TRASH_DAYS)
- WordPress Developer Resources: Database Description (az alaptáblák szerepe)
- WordPress Support (HelpHub): Revisions, Comment Moderation
- WP-CLI Handbook: wp db, wp post, wp transient, wp comment parancsok
- Transients API dokumentáció, WordPress Developer Resources
- MySQL Reference Manual: INFORMATION_SCHEMA TABLES, OPTIMIZE TABLE
- MariaDB Knowledge Base: InnoDB tárolómotor és táblaújraépítés
- Action Scheduler dokumentáció (WooCommerce)
- Google Search Central: oldalélmény és Core Web Vitals útmutatók
- web.dev: Time to First Byte és szerveroldali válaszidő optimalizálása
- Előbb mérj táblánként, csak utána törölj: a méret és a sorszám együtt mutatja meg, hol van a valódi probléma.
- A revíziók, az automatikus mentések, a lomtár, a spam és a lejárt transientek biztonsággal takaríthatók, teljes adatbázis-mentés után.
- A felhasználói, rendelési és licenckulcs-adatokhoz, valamint a futásra váró ütemezett feladatokhoz ne nyúlj.
- Az autoload értékű beállítások mérete gyakran többet számít a válaszidőben, mint az adatbázis teljes mérete.
- A wp-config.php néhány sora (revíziószám, lomtár-ürítés, mentési gyakoriság) hosszú távon többet ér, mint egy nagytakarítás.
Gyakori kérdések
Törölhetem az összes revíziót nyugodtan?
Az élő tartalmat nem érinti, tehát technikailag igen, de teljes adatbázis-mentés után csináld, és inkább hagyj meg bejegyzésenként néhányat. A revízió akkor ér a legtöbbet, amikor valaki véletlenül felülír egy jó szöveget.
Honnan tudom, hogy egy tábla melyik bővítményhez tartozik?
Keress rá a tábla nevére a táblaelőtag után, majd nézd meg, szerepel-e az aktív vagy a kikapcsolt bővítmények között. Ha egyikben sincs, valószínűleg egy eltávolított bővítmény maradéka. Eldobás helyett előbb nevezd át, és figyeld egy-két hétig, jelentkezik-e hiba.
Miért nem tűnnek el maguktól a lejárt átmeneti adatok?
A lejárati idő nem jelent automatikus törlést. A WordPress jellemzően akkor takarítja el a lejárt sort, amikor legközelebb ugyanazt a kulcsot kérik. Ha a kulcsot már senki nem kéri, a sor a helyén marad. Objektum-gyorsítótárral ezek ki sem kerülnek az adatbázisba.
Gyorsabb lesz az oldal a takarítás után?
Előfordul, de nem törvényszerű. Akkor szokott érezhető javulást hozni, ha az automatikusan betöltődő beállítások mérete kiugró, ha a szerkesztőfelület lassult be, vagy ha egy milliós naplótáblát kérdez le rendszeresen valamelyik bővítmény. Ha a lassulás oka kép, gyorsítótár-hiány vagy gyenge tárhely, az adatbázis-takarítás nem segít.
Elég egy takarító bővítmény, vagy kell hozzá SQL?
A rutinfeladatokra (revíziók, lomtár, spam, lejárt transientek) egy jó nevű takarító bővítmény bőven elég, és biztonságosabb is, mert kötegelve dolgozik. SQL-re a felmérésnél és a maradékok azonosításánál van szükség, mert azt bővítmény nem tudja megbízhatóan eldönteni helyetted.
Milyen gyakran érdemes ránézni az adatbázis méretére?
Negyedévente egy ötperces ellenőrzés általában elég: ugyanaz a táblaméret-lekérdezés, és a korábbi értékkel összevetve nézed a trendet. A trend többet mond, mint a pillanatnyi méret.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.