Se hai un database WordPress lento, la soluzione non è necessariamente installare un plugin di pulizia e cancellare revisioni, transient e tabelle a caso. Un database molto grande può funzionare correttamente, mentre uno più piccolo può rallentare il sito a causa di query inefficienti, opzioni caricate inutilmente o plugin che interrogano continuamente gli stessi dati.
La priorità è quindi capire cosa sta rallentando realmente WordPress. Solo dopo ha senso intervenire sul database.
In breve: misura le query, individua il componente responsabile, controlla autoload e tabelle che crescono e correggi la causa prima di procedere con pulizie o sistemi di cache.
Perché il database WordPress può diventare lento?
WordPress utilizza il database per recuperare contenuti, impostazioni, utenti e numerose informazioni generate da temi e plugin.
Il problema nasce quando queste operazioni diventano più pesanti del necessario.
Le cause più comuni sono:
- query lente o ripetute troppe volte;
- opzioni autoload troppo pesanti;
- plugin che effettuano interrogazioni inefficienti;
- transient accumulati;
- tabelle cresciute eccessivamente;
- revisioni e dati non più necessari;
- log che continuano ad aumentare;
- grandi quantità di dati in
wp_postmeta; - attività pianificate che generano continuamente nuovi record;
- assenza di object cache nei siti che ne beneficerebbero;
- risorse insufficienti del server MySQL o MariaDB.
Un concetto importante è che database grande e database lento non sono sinonimi.
Un e-commerce può avere un database di diversi gigabyte e funzionare correttamente. Al contrario, poche query particolarmente costose possono rallentare anche un sito con un database relativamente piccolo.
Come capire se è davvero il database a rallentare WordPress
Prima di eliminare qualsiasi dato bisogna verificare che il database sia realmente uno dei colli di bottiglia.
Un primo segnale può essere un pannello WordPress lento mentre il frontend sembra veloce. La page cache può infatti servire ai visitatori pagine già generate, mentre /wp-admin/ continua a eseguire codice PHP e query dinamiche.
Altri segnali da controllare sono:
- TTFB elevato;
- backend molto lento;
- salvataggio di articoli o prodotti che richiede diversi secondi;
- query particolarmente lente;
- numerose query duplicate;
- tabelle che aumentano rapidamente di dimensione;
- rallentamenti comparsi dopo l’installazione o l’aggiornamento di un plugin.
Uno degli strumenti più utili per approfondire è Query Monitor.
Permette di analizzare le query eseguite durante una richiesta e di verificare:
- quali sono più lente;
- quali vengono ripetute;
- eventuali errori;
- quale plugin, tema o componente le genera;
- quanto tempo viene complessivamente impiegato nelle interrogazioni del database.
Il numero totale delle query, da solo, non dice molto. Cento query rapide possono essere meno problematiche di cinque query molto costose.
Query Monitor è uno strumento diagnostico: utilizzalo durante l’analisi e disattivalo quando non ti serve, soprattutto sui siti con risorse limitate.
Se non riesci a distinguere un problema del database da uno causato da plugin, hosting o codice, una consulenza WordPress può aiutarti a individuare la causa prima di modificare dati e configurazioni.
Controlla wp_options e le opzioni autoload
Una delle prime tabelle da verificare è wp_options.
Qui WordPress e molti plugin memorizzano impostazioni necessarie al funzionamento del sito. Alcune vengono configurate come autoload, cioè vengono caricate automaticamente durante molte richieste.
Questo comportamento è corretto per le informazioni utilizzate frequentemente. Diventa invece inefficiente quando vengono caricate automaticamente grandi quantità di dati non necessari.
WordPress include un controllo specifico nel Site Health.
Puoi verificare da:
Strumenti → Salute del sito
se vengono segnalate anomalie relative alle opzioni caricate automaticamente.
La documentazione WordPress utilizza 800.000 byte come soglia predefinita per segnalare un possibile problema relativo ai dati autoload. Non significa però che superare questa cifra renda automaticamente lento il sito: è un riferimento diagnostico, non una regola universale.
Non bisogna quindi disattivare indiscriminatamente l’autoload.
La cosa corretta è individuare:
- opzioni particolarmente grandi;
- dati appartenenti a plugin rimossi;
- configurazioni non più utilizzate;
- valori che non hanno realmente bisogno di essere caricati ad ogni richiesta.
Puoi approfondire nella documentazione ufficiale WordPress sulle performance.
Transient e revisioni: vanno sempre eliminati?
No. Possono contribuire alla crescita del database, ma non sono automaticamente la causa della lentezza.
I transient sono dati temporanei utilizzati da WordPress e dai plugin per conservare informazioni riutilizzabili. Senza una object cache persistente possono essere memorizzati nel database.
Eliminare transient scaduti può essere utile, ma cancellarli continuamente non rende necessariamente WordPress più veloce. Molti verranno semplicemente ricreati.
Se continuano ad accumularsi, è più utile capire quale plugin o processo li genera.
Lo stesso vale per le revisioni.
WordPress conserva versioni precedenti di pagine e articoli. Su siti editoriali molto attivi possono diventare numerose, ma rimuoverle non significa automaticamente velocizzare le query problematiche.
Se vuoi limitarne il numero puoi utilizzare:
define( 'WP_POST_REVISIONS', 5 );
In questo esempio WordPress conserva fino a cinque revisioni per contenuto.
Pulire dati inutili può quindi aiutare a mantenere il database ordinato, ma non deve sostituire una vera diagnosi.
Individua le tabelle che stanno crescendo troppo
Un controllo molto utile consiste nel verificare quali tabelle occupano più spazio.
Se hai accesso a WP-CLI puoi utilizzare:
wp db size --tables --human-readable --orderby=size
Il comando mostra le dimensioni delle singole tabelle e del database complessivo.
Una tabella grande non è necessariamente problematica. Diventa interessante quando:
- cresce molto rapidamente;
- appartiene a un plugin non più utilizzato;
- contiene log che non vengono mai eliminati;
- presenta un numero anomalo di record;
- viene interrogata frequentemente da query lente.
È particolarmente utile controllare come cambia la dimensione nel tempo.
Una tabella stabile da 1 GB può essere perfettamente normale per un progetto complesso. Una tabella che passa rapidamente da 200 a 800 MB merita invece attenzione.
Puoi consultare anche la documentazione ufficiale di wp db size.
Attenzione a wp_postmeta e ai plugin più complessi
La tabella wp_postmeta contiene informazioni aggiuntive associate ai contenuti e può diventare molto grande sui siti che utilizzano:
- WooCommerce;
- page builder;
- custom field;
- filtri avanzati;
- plugin che registrano numerosi metadati.
La dimensione da sola non rappresenta un errore.
Il problema può emergere quando query frequenti devono cercare informazioni all’interno di grandi quantità di metadati oppure quando un plugin genera continuamente nuovi record.
Per questo non bisogna cancellare dati da wp_postmeta soltanto perché la tabella è grande.
Prima bisogna capire:
- quali dati contiene;
- quale componente li utilizza;
- quali query vengono eseguite;
- se esistono record realmente inutilizzati.
Anche i plugin possono essere responsabili di una parte importante del problema. Un componente può interrogare il database decine di volte nella stessa richiesta, eseguire query anche dove non servono oppure generare continuamente log e dati temporanei.
In questi casi eliminare revisioni e transient produce benefici marginali: bisogna correggere il componente responsabile.
Anche le query e gli indici possono essere il problema
Una query può essere lenta perché deve analizzare una grande quantità di record prima di trovare quelli richiesti.
Nei database MySQL e MariaDB gli indici aiutano a recuperare determinate informazioni più rapidamente.
Su siti complessi, query lente possono dipendere dalla struttura della query, dalle colonne utilizzate nei filtri o da indici non adatti a quel tipo di ricerca.
Un’analisi tecnica può utilizzare strumenti come EXPLAIN per capire come il database esegue una determinata query.
Non è però un intervento da fare alla cieca.
Aggiungere indici o modificare il database senza aver prima identificato il problema può essere inutile o addirittura peggiorare altri tipi di operazioni.
WooCommerce: controlla anche le attività pianificate
Su WooCommerce conviene controllare anche le attività eseguite in background.
WooCommerce e numerosi plugin utilizzano Action Scheduler per gestire operazioni come:
- webhook;
- email;
- sincronizzazioni;
- processi relativi agli ordini;
- integrazioni esterne.
Un numero molto elevato di attività fallite o continuamente riprogrammate può contribuire alla crescita del database e rallentare alcune operazioni del backend.
Se il problema riguarda un e-commerce, quindi, non limitarti a revisioni e transient: verifica anche le attività pianificate.
Come ottimizzare un database WordPress lento in modo sicuro
La sequenza più corretta è:
misurare → fare un backup → individuare la causa → intervenire → verificare.
1. Misura prima di modificare
Annota almeno:
- tempo di caricamento della stessa pagina;
- tempo dedicato alle query;
- numero di query;
- dimensione del database;
- tabelle più grandi;
- quantità di dati autoload.
In questo modo potrai capire se l’intervento produce un miglioramento reale.
2. Crea un backup
Prima di modificare o eliminare dati, esegui un backup del database e assicurati che sia possibile ripristinarlo.
È fondamentale soprattutto su WooCommerce, membership, siti di prenotazioni e portali che ricevono continuamente nuovi dati.
3. Individua il componente responsabile
Utilizza Query Monitor, Site Health, WP-CLI o gli strumenti diagnostici dell’hosting per cercare:
- query lente;
- query duplicate;
- tabelle in crescita;
- autoload eccessivo;
- plugin problematici;
- attività pianificate anomale.
Partirei sempre dalla diagnosi prima di eliminare revisioni o transient, perché ridurre il peso del database non significa necessariamente eliminare il collo di bottiglia.
4. Elimina solo dati identificati
Puoi valutare la rimozione di:
- revisioni non più necessarie;
- transient scaduti;
- commenti spam;
- contenuti nel cestino;
- vecchi log;
- opzioni di plugin definitivamente rimossi;
- tabelle residue identificate con certezza.
Non cancellare una tabella semplicemente perché non riconosci il nome.
5. Correggi la causa
Se un plugin genera ogni settimana migliaia di nuovi record inutili, pulire periodicamente il database non è una soluzione.
Bisogna aggiornare, riconfigurare, sostituire o correggere il componente responsabile.
6. Verifica il risultato
Dopo l’intervento ripeti le misurazioni iniziali.
L’ottimizzazione è realmente utile quando migliora:
- tempi di risposta;
- tempo delle query;
- velocità del backend;
- comportamento generale del sito.
Ridurre semplicemente il database di qualche megabyte non è un risultato sufficiente.
Redis e object cache possono aiutare?
Sì, in alcuni siti.
Una persistent object cache può conservare in memoria dati già recuperati e ridurre il numero di accessi ripetuti al database.
Soluzioni come Redis possono essere particolarmente utili su:
- WooCommerce;
- membership;
- portali;
- siti con utenti autenticati;
- applicazioni WordPress molto dinamiche.
È importante distinguere object cache e page cache.
La page cache conserva una pagina già generata. L’object cache conserva invece dati e oggetti utilizzati da WordPress durante l’elaborazione delle richieste.
Redis non corregge però automaticamente query inefficienti o plugin che continuano a generare dati inutili.
Prima si risolve la causa, poi si utilizza la cache per rendere più efficiente ciò che rimane.
Puoi approfondire nella documentazione ufficiale di WP_Object_Cache.
Cosa evitare quando il database WordPress è lento
Evita soprattutto di:
- eliminare tabelle che non hai identificato;
- cancellare indiscriminatamente record da
wp_postmeta; - disattivare l’autoload su tutte le opzioni;
- eseguire query SQL trovate online senza comprenderle;
- installare più plugin di pulizia contemporaneamente;
- utilizzare Redis per nascondere query inefficienti;
- giudicare il risultato soltanto dalla dimensione del database.
L’ottimizzazione migliore è quasi sempre selettiva e misurabile.
Come evitare che il problema ritorni
Dopo aver risolto la causa, controlla periodicamente:
- dimensioni delle principali tabelle;
- crescita del database;
- Site Health;
- dati autoload;
- plugin non più necessari;
- log;
- transient;
- attività pianificate;
- prestazioni del backend.
Questi controlli possono rientrare in una normale attività di manutenzione del sito WordPress.
Prima trova il collo di bottiglia, poi pulisci il database
Quando WordPress rallenta, il database è sicuramente uno degli elementi da controllare, ma non va trattato come un contenitore da svuotare periodicamente.
La sequenza corretta resta:
diagnosi → backup → intervento → verifica.
In alcuni casi il problema sarà un autoload eccessivo. In altri una query specifica, un plugin, una tabella che continua a crescere oppure l’infrastruttura del server.
Se il backend è lento, il database continua a crescere o non riesci a individuare il componente responsabile, puoi contattarmi per un’analisi tecnica del sito WordPress.
FAQ
Un database WordPress grande è necessariamente lento?
No. La dimensione è soltanto uno dei parametri da valutare. Un database grande con query efficienti può funzionare correttamente, mentre uno più piccolo può rallentare WordPress a causa di query inefficienti, autoload eccessivo o plugin problematici.
Quanto dovrebbero pesare le opzioni autoload?
WordPress utilizza nel Site Health una soglia predefinita di 800.000 byte per segnalare un possibile problema relativo alle opzioni autoload. È un valore diagnostico, non un limite universale valido per tutti i siti.
Perché il backend è lento ma il sito pubblico è veloce?
La page cache può servire rapidamente pagine già generate, mentre il pannello amministrativo continua a eseguire PHP, query dinamiche e attività pianificate. Per questo alcuni problemi del database risultano più evidenti in /wp-admin/.
Come posso trovare le query lente di WordPress?
Query Monitor permette di individuare query lente, duplicate o errate e di verificare quale plugin, tema o componente le sta generando.
Redis risolve un database WordPress lento?
Non necessariamente. Redis può ridurre gli accessi ripetuti al database tramite una object cache persistente, ma non corregge query inefficienti, plugin problematici o tabelle che continuano a crescere.
