Először profilozza a lassú oldalt vagy adminisztratív műveletet, és azonosítsa a konkrét lekérdezést. Ellenőrizze a táblák növekedését, az automatikusan betöltött (autoload) options bejegyzéseket, az ütemezett feladatokat és az eltávolított pluginek adatait. A törlést és az indexeket stagingen, biztonsági mentéssel próbálja ki; a módosítás után ellenőrizze a funkciókat, a naplókat és a méréseket, ne csak az adatbázis méretét.
A WordPress-adatbázis optimalizálása ne a „minden törlése” gombbal kezdődjön. Az adatbázis tárolja a tartalmat, a beállításokat, a felhasználókat, a kapcsolatokat és a bővítmények adatait is. Egy nagy tábla nem feltétlenül lassú, egy kis táblában pedig lehet index nélküli hibás lekérdezés. A revíziók vagy transientek mechanikus törlése ezért gyakran csekély hatással jár, miközben egy ismeretlen rendelési vagy sorbeli rekord pótolhatatlan lehet.
A helyes eljárás megméri a konkrét lassú kérést, azonosítja a lekérdezéseket, és csak ezután dönt az adat-, alkalmazás- vagy szerverszintű beavatkozásról. Minden változtatást a valós adatmennyiség másolatán, visszaállítható biztonsági mentéssel kell kipróbálni. A cikk a WordPress-adatbázis leggyakoribb területeit ismerteti olyan univerzális parancsok nélkül, amelyek egy eltérő telepítést károsíthatnának.
Mérje a problémát egy konkrét kérésen
Különböztesse meg a lassú nyilvános oldalt, a keresést, a cikk mentését, a rendelések listáját vagy az ütemezett feladatot. Mindegyik útvonal más táblákat használ. Egy profilozó eszköz vagy az adatbázis slow query logja megmutatja az időt, a hívások számát és az ismétlődést. Ugyanaz a százszor végrehajtott lekérdezés nagyobb probléma lehet, mint egyetlen kissé lassú lekérdezés.
Reprezentatív felhasználóval, paraméterekkel és cache-állapottal mérjen. Rögzítse a kód verzióját, az adatok méretét és a beavatkozás előtti időt. Terv nélkül ne kapcsoljon ki indexeket, és ne futtasson erőforrás-igényes elemzést éles csúcsidőben. Ha a lassúságot egy külső API vagy egy PHP-számítás okozza, az adatbázis tisztítása csak elvonja a figyelmet.
Leltározza fel a táblázatokat és azok felelőseit
Kérje le a táblák listáját, az adatok és indexek méretét, a sorok számát és a növekedés ütemét. Az előtag segít megbecsülni az eredetet, de nem bizonyítja, hogy a tábla törölhető. Derítse ki, melyik plugin, egyedi kód vagy integrációs folyamat használja. Multisite esetén vegye figyelembe a hálózati és a webhelyszintű táblákat is. Az ismeretlen táblát először archiválja és tesztelje.
A nagy napló- vagy várakozásisor-táblák megőrzési beállítása lehet nem megfelelő, vagy a feldolgozásuk meghiúsulhatott. A megoldás a növekedés forrásának kijavítása és biztonságos életciklus bevezetése, nem pedig a tünet rendszeres kézi törlése. A rendelési, tagsági és űrlapadatokra üzemeltetési vagy jogi követelmények vonatkozhatnak, amelyeket az adatok tulajdonosának kell megerősítenie.
- Méret és növekedési ütem
- A táblát birtokló bővítmény vagy folyamat
- Megőrzési szabály és cél
- Helyreállítási eljárás az eltávolítás előtt
Ellenőrizze az options táblát és az autoloadot
Az automatikusan betöltött (autoload) options értékek számos kérésnél betöltődnek. A probléma akkor jelentkezik, amikor egy plugin nagy objektumot vagy folyamatosan növekvő naplót tárol automatikusan betöltött beállításként. Rendezze az értékeket méret szerint, azonosítsa a tulajdonosukat, és ellenőrizze, hogy valóban szükség van-e rájuk minden betöltéskor. Ne módosítsa kézzel az értéket a szerializáció és az elvárt formátum megértése nélkül.
Az eltávolított bővítmények beállításokat hagyhatnak maguk után, de egy régi bővítményhez hasonló nevet továbbra is használhat egy másik összetevő. A változtatást először stagingen próbálja ki, és figyelje az adminisztrációt és a front-endet is. A nagy, aktív konfiguráció kódmódosítással áthelyezhető, feldarabolható vagy igény szerint betölthető. Önmagában az autoload kikapcsolása csökkentheti az egyik terhelést, ugyanakkor megnövelheti a különálló lekérdezések számát.
A revíziókat, a transienteket és a metaadatokat szabály szerint tisztítsa
A revíziók védik a szerkesztői munkát, és lehetővé teszik a visszaállítást, ezért számukat a módosítások gyakorisága és az audit igényei szerint állítsa be. Az összes verzió tömeges törlése megfoszthatja a csapatot a hasznos előzményektől. A transientek ideiglenes cache-értékek, de nem minden bővítmény távolítja el megfelelően a lejárt bejegyzéseket. Először derítse ki, hogy növekedésük összefügg-e az ütemezett feladatok hibájával.
A bejegyzések és felhasználók metaadatai megmaradhatnak az objektum törlése vagy egy bővítmény cseréje után. Az árva rekordokat egy másolaton futtatott biztonságos lekérdezéssel azonosítsa, és ellenőrizzen egy mintát. WooCommerce vagy saját adatrétegek esetén ne használjon általános tisztítóeszközt igazolt kompatibilitás nélkül. Az eltávolítás után csak akkor optimalizálja a táblát, ha a haszon releváns, és a karbantartási ablak elbírja a szükséges zárolást.
- Revíziók megőrzése a szerkesztőség igényei szerint
- Lejárt gyorsítótár-adatok tulajdonos szerint
- Árva elemek mintán ellenőrizve
- Az ismeretlen meta kulcsok tömeges törlése nélkül
Az indexekről és a sémaváltozásokról bizonyítékok döntsenek
Egy hiányzó index lassíthatja egy nagy tábla szűrését, a felesleges index viszont lassítja az írásokat és helyet foglal. A tervezés a konkrét lekérdezés végrehajtási tervéből, a szelektivitásból és a tényleges adatmennyiségből indul ki. Hozzáadás előtt ellenőrizze a meglévő indexeket és a plugin jövőbeli migrációival való kompatibilitást. Egy idegen táblához hozzáadott saját indexet dokumentáljon, mert a frissítés nem feltétlenül ismeri.
A sémamódosítást ellenőrzötten vezesse be, időbecsléssel, biztonsági mentéssel és visszaállítási lehetőséggel. A beavatkozás után ismételje meg ugyanazt a profilozást, hasonlítsa össze az időket, és ellenőrizze az írásokat, az importokat, a szerkesztőt és a biztonsági mentést is. Kövesse a további növekedést, hogy a probléma ne térjen vissza. A legjobb eredmény a megszüntetett kiváltó ok és a mérhetően gyorsabb forgatókönyv, nem csupán egy kisebb megabájtszám.
Gyakori kérdések
Biztonságos törölni a WordPress összes revízióját?
Nem a szerkesztőségi igény és a mentés felmérése nélkül. A revíziók lehetővé teszik a visszatérést a korábbi tartalomhoz. Célszerűbb megfelelő megőrzési időt beállítani, és a régebbi bejegyzéseket teszt után, ellenőrzötten törölni.
Egy kisebb adatbázis automatikusan gyorsabbá teszi a weboldalt?
Nem. A teljesítmény a konkrét lekérdezésektől, indexektől, gyorsítótártól, szervertől és alkalmazáskódtól függ. A kérés során nem használt adatok törlése nem feltétlenül hoz mérhető változást. Először profilozza a forgatókönyvet.
Használhatok bővítményt az adatbázis tisztítására?
Segíthet az ismert, biztonságos kategóriáknál, de az automatikus megjelölés nem jelent garanciát. Ellenőrizze a kompatibilitást és az adatok tulajdonosát, készítsen biztonsági mentést, és az eredményt először stagingkörnyezetben, valós funkciókkal ellenőrizze.
Források és további olvasnivaló
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.
