Cum optimizezi baza de date WordPress: revizii, tabele umflate și curățare

Dacă site-ul a devenit lent fără un motiv clar, uită-te și în baza de date. Acolo WordPress ține articolele, paginile, setările, utilizatorii și comentariile. Cu timpul, ea strânge și multe date de care nu mai ai nevoie. Optimizarea bazei de date WordPress înseamnă să scoți aceste date și să lași tabelele curate.

Mai jos găsești ce se adună, cum cureți în siguranță, cu backup înainte, și cum oprești umflarea pe viitor.

De ce se umflă baza de date WordPress

WordPress salvează mult mai mult decât conținutul pe care îl vezi. Fiecare articol își păstrează istoricul modificărilor. Multe pluginuri își creează tabele și setări proprii. Temele lasă setări în urmă și după ce le dezinstalezi.

Astfel, o bază de date de câțiva megaocteți poate ajunge la sute de megaocteți. Diferența o fac datele rămase în urmă. O bază de date umflată face mai lentă fiecare interogare (cererea prin care site-ul citește date). Backupurile durează mai mult, iar la trafic mare crește riscul de blocaje.

Reviziile, cea mai frecventă sursă de umflare

Când salvezi o pagină sau un articol, WordPress creează o revizie, adică o copie a conținutului. Un articol editat de 40 de ori are 40 de copii în tabelul wp_posts. Pe sute de articole, reviziile devin de departe prima sursă de umflare.

Nu le elimina de tot. Cu ele revii la o versiune anterioară, de exemplu la un rollback în WordPress după o actualizare eșuată. Mai bine limitezi câte se păstrează. Deschide wp-config.php (fișierul de setări al site-ului) și adaugă linia de mai jos deasupra comentariului care începe cu „That’s all, stop editing”:

define( 'WP_POST_REVISIONS', 5 );

De acum, WordPress păstrează ultimele 5 revizii pentru fiecare articol. Pe cele mai vechi le șterge singur, la următoarea salvare a unei modificări în articol.

Ce altceva umflă tabelele

• Transients expirate: date temporare de cache, lăsate de pluginuri în tabelul wp_options mult după ce au expirat.
• Comentarii spam și în așteptare: pot fi mii, fiecare cu datele lui.
• Coșul de gunoi: articole, pagini și comentarii șterse, dar nu definitiv.
• Metadate orfane: rânduri rămase de la pluginuri sau articole care nu mai există.
• Tabele orfane: create de pluginuri și teme dezinstalate care nu și-au șters urmele.

Unele dintre aceste date încetinesc site-ul direct. Opțiunile cu încărcare automată (autoload) din wp_options se citesc la fiecare afișare de pagină. Câțiva megaocteți de opțiuni inutile încărcate automat pot încetini tot site-ul, la fiecare vizită.

Despre ele am scris separat, în opțiuni autoload și transient-uri: cum scapi de datele care umflă baza. Documentația oficială Transients API arată că un transient poate dispărea oricând, iar pluginul care l-a creat trebuie să-l poată recrea.

Ce câștigi după curățare

O bază de date curată răspunde mai repede la interogări. Paginile se încarcă mai repede, iar panoul de administrare reacționează mai prompt. Backupurile devin mai mici și se fac mai repede. Mutarea pe alt server e mai simplă.

Scade și efortul serverului. Asta contează mult pe hostingul partajat, unde resursele sunt împărțite cu alte site-uri.

Înainte de orice: backup verificat

Ștergerea din baza de date nu are buton de anulare. O comandă greșită poate șterge exact tabelele de care depinde tot site-ul. De aceea primul pas e un backup complet: fișierele și baza de date.

Apoi verifică dacă backupul chiar se poate restaura. Nu ajunge să existe fișierul. Pașii îi găsești în ghidul despre cum faci backup la un site WordPress.

Ideal, faci curățarea întâi pe o copie de test a site-ului (staging). Pe site-ul real o aplici doar după ce ai văzut că totul merge. Află ce este un site de staging și cum îl folosești.

Optimizare bază de date WordPress, pas cu pas

Ordinea contează: întâi ștergi, apoi optimizezi tabelele, la final verifici site-ul.

1. Șterge datele inutile, câte o categorie

Pentru majoritatea site-urilor ajunge un plugin, fără cod. WP-Optimize sau Advanced Database Cleaner fac curățarea dintr-o interfață simplă. Bifează pe rând reviziile, comentariile spam, transients expirate, metadatele orfane și coșul de gunoi.

Nu bifa totul din prima. Mergi categorie cu categorie și verifică site-ul între pași.

Dacă folosești WP-CLI (unealta care comandă WordPress din terminal), două comenzi fac o parte din curățare: transients expirate și reviziile.

wp transient delete --expired
wp post delete $(wp post list --post_type=revision --post_status=inherit --format=ids) --force

Prima șterge transients expirate. A doua șterge definitiv toate reviziile, deci și versiunile la care ai putea reveni. Rulează-o doar după backup. Construcția $(...) merge în terminale de tip bash, pe Linux și macOS. În PowerShell sau cmd, pe Windows, nu merge.

Nu improviza interogări DELETE direct în MySQL pe tabelele WordPress, dacă nu știi exact ce ștergi. Acolo apar cele mai multe accidente ireversibile.

2. Optimizează tabelele

După ștergere, rulează comanda OPTIMIZE TABLE. Ea reconstruiește tabelele și poate recupera spațiul rămas liber. O găsești în plugin și în phpMyAdmin (interfața web a bazei de date). Scrisă în SQL, arată așa:

OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options;

Dacă prefixul tabelelor tale nu e wp_, schimbă-l în comandă. Îl vezi în wp-config.php, la $table_prefix. Pe tabelele InnoDB, MySQL răspunde cu „Table does not support optimize, doing recreate + analyze instead”. E un mesaj normal: tabelul se reconstruiește oricum.

Pe tabelele MyISAM, MySQL blochează tabelul cât rulează comanda. Rulează-o când site-ul are puțini vizitatori.

3. Verifică site-ul

Deschide câteva pagini, panoul de administrare și formularele. Dacă ceva nu merge, restaurezi backupul făcut la început.

Motorul tabelelor: InnoDB sau MyISAM

Verifică și ce motor de stocare folosesc tabelele. InnoDB gestionează mai bine scrierile simultane și rezistă mai bine la coruperea datelor decât vechiul MyISAM. Site-urile mai vechi pot avea încă tabele MyISAM. În phpMyAdmin, motorul apare în lista tabelelor, la coloana „Type” („Tip” în interfața în română).

Conversia se face tabel cu tabel, tot după backup:

ALTER TABLE wp_posts ENGINE=InnoDB;

După conversie, verifică din nou site-ul.

Cum oprești umflarea pe viitor

Pe lângă limita de revizii, poți goli automat coșul de gunoi. Adaugă în wp-config.php, tot deasupra comentariului „That’s all, stop editing”:

define( 'EMPTY_TRASH_DAYS', 7 );

Așa, WordPress golește singur coșul după 7 zile. Fără linia asta, o face după 30 de zile.

O curățare făcută o singură dată rezolvă problema de azi, dar baza de date se umflă din nou în câteva luni. Programează o curățare lunară și limitează reviziile de la început.

Curățarea bazei de date în mentenanța WordPress

Dacă nu vrei să te ocupi singur, optimizarea bazei de date e inclusă în unele dintre abonamentele noastre de mentenanță WordPress. Ce include fiecare plan vezi pe pagina abonamente. Dacă vrei să afli întâi în ce stare e site-ul tău, cere un audit gratuit.

Citește și: De ce ai nevoie de un jurnal de modificări (changelog) pentru site.