Un database WordPress lento richiede una diagnosi basata su query, dimensione delle tabelle, opzioni autoload, cron, plugin e traffico. Prima di cancellare o ottimizzare dati crea un backup, individua le operazioni costose e intervieni sulla causa. Le pulizie automatiche indiscriminate possono danneggiare il sito senza risolvere il problema.
WordPress utilizza MySQL o MariaDB per contenuti, impostazioni, utenti, sessioni applicative e dati dei plugin. Con il tempo il database può crescere, ma la dimensione da sola non spiega sempre la lentezza. Un database piccolo con query inefficienti può essere più lento di uno grande e ben indicizzato.
Questa guida spiega come diagnosticare un database WordPress lento e distinguere tabelle grandi, autoload eccessivo, revisioni, transients, query lente e attività pianificate.
Sintomi di un database lento
- bacheca WordPress lenta;
- salvataggio di articoli o prodotti che impiega molti secondi;
- ricerca e filtri lenti;
- timeout durante importazioni o aggiornamenti;
- CPU elevata durante richieste dinamiche;
- molti processi PHP in attesa;
- errori 508, 500 o 503 durante picchi;
- query lente registrate da strumenti diagnostici;
- wp-admin più lento delle pagine pubbliche in cache.
Il sintomo può dipendere anche da plugin, API esterne, disco o risorse. Consulta prima Sito lento.
Prima di modificare il database
- crea un backup recente;
- verifica che il backup sia scaricabile o ripristinabile;
- annota prefisso e nome del database;
- esegui le operazioni in un periodo con poco traffico;
- non lavorare contemporaneamente su file e database;
- prova prima su staging quando il sito è critico;
- documenta ogni query eseguita manualmente.
Per il ripristino consulta Ripristinare un database con JetBackup 5.
Controlla dimensione delle tabelle
Da phpMyAdmin seleziona il database e ordina le tabelle per dimensione. Controlla dati e indici separatamente. Tabelle molto grandi possono appartenere a:
- ordini e prodotti WooCommerce;
- log di sicurezza;
- statistiche e analytics;
- code di email;
- sessioni;
- attività pianificate;
- cache e transients;
- plugin eliminati che hanno lasciato dati.
Non svuotare una tabella soltanto perché è grande. Identifica il plugin proprietario e la sua politica di conservazione.
Che cos’è l’autoload di wp_options
La tabella wp_options contiene impostazioni che WordPress e i plugin possono caricare automaticamente a ogni richiesta. Se il totale autoload diventa elevato, ogni pagina dinamica trasferisce e deserializza più dati.
Puoi misurare indicativamente il totale con una query adattata al formato del campo autoload della tua versione:
SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto');Il prefisso potrebbe non essere wp_. Non modificare valori senza sapere a quale plugin appartengono.
Individua le opzioni autoload più grandi
SELECT option_name,
LENGTH(option_value) AS bytes,
autoload
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto')
ORDER BY bytes DESC
LIMIT 50;Controlla nomi, dimensione e componente proprietario. Un valore grande può essere legittimo. Prima di eliminarlo:
- verifica che il plugin non sia attivo;
- cerca una funzione di pulizia ufficiale;
- esporta la riga;
- prova su staging;
- controlla se viene ricreata.
Revisioni, bozze e cestino
Le revisioni permettono di recuperare versioni precedenti degli articoli. Un sito editoriale può accumularne molte. Prima di ridurle valuta esigenze legali, editoriali e di rollback.
WordPress permette di limitare le revisioni future con una costante in wp-config.php:
define('WP_POST_REVISIONS', 10);Non inserire la costante due volte. La cancellazione delle revisioni esistenti deve essere eseguita con uno strumento affidabile e dopo un backup.
Transients scaduti
I transients memorizzano temporaneamente dati costosi da calcolare. In condizioni normali WordPress e i plugin li gestiscono automaticamente, ma alcuni componenti possono lasciarne molti.
Non eliminare continuamente tutti i transients. La cache dovrà essere ricostruita e il carico potrebbe aumentare. Rimuovi quelli scaduti con strumenti compatibili e controlla quale plugin genera una crescita anomala.
Con Redis Object Cache, alcuni transient possono essere conservati nel backend persistente anziché nel database. Consulta Redis Object Cache su WordPress.
Action Scheduler e code WooCommerce
WooCommerce e numerosi plugin utilizzano Action Scheduler per operazioni in background. Tabelle con milioni di azioni completate o fallite possono rallentare amministrazione e cron.
Da WordPress controlla gli strumenti delle azioni pianificate, gli errori e il componente che continua a creare eventi. Non cancellare la coda durante pagamenti, ordini, sincronizzazioni o invii in corso.
Correggi prima la causa delle azioni fallite; una pulizia senza correzione produce una nuova crescita.
Query lente e plugin
Utilizza un ambiente di test o uno strumento diagnostico per vedere:
- query più lente;
- numero totale di query;
- componente che le genera;
- query duplicate;
- chiamate HTTP esterne;
- tempo PHP e database separati.
Query Monitor può essere utile agli amministratori tecnici, ma non deve rimanere attivo indiscriminatamente su un sito molto trafficato. Disattivalo dopo la diagnosi.
Indici mancanti
Le query su grandi tabelle possono richiedere indici adeguati. Non aggiungere indici generici copiati da Internet: aumentano spazio e costo delle scritture e possono essere incompatibili con gli aggiornamenti del plugin.
Raccogli la query, usa EXPLAIN in ambiente controllato e confronta la struttura prevista dal produttore. Per tabelle appartenenti a plugin, preferisci aggiornamenti o procedure ufficiali.
Ottimizzare le tabelle
La funzione di ottimizzazione può recuperare spazio e riorganizzare tabelle dopo numerose cancellazioni, ma non deve essere eseguita come rimedio universale. Su tabelle grandi può bloccare o rallentare il sito.
Con WP-CLI:
wp db check
wp db optimizeEsegui i comandi dalla Document Root corretta, con backup e in una finestra di manutenzione. Verifica prima che WP-CLI utilizzi il sito e il database previsti.
WP-Cron e query ripetute
Eventi pianificati troppo frequenti possono interrogare continuamente il database. Controlla cron duplicati, eventi scaduti e plugin che pianificano nuove attività a ogni caricamento.
Se sostituisci WP-Cron con un Cron Job reale, segui Cron Job in cPanel e WP-Cron. Non disabilitare WP-Cron senza configurare un’alternativa.
Database e memoria PHP
Una query può restituire molti dati che PHP deve poi elaborare. Aumentare memory_limit può evitare un errore immediato, ma non rende efficiente una query e può aumentare il consumo per processo.
Consulta Allowed memory size exhausted e modifica i valori da Select PHP Version quando il dominio utilizza CloudLinux PHP Selector.
Cache oggetti e database
Una cache oggetti persistente può ridurre query ripetute, ma non corregge dati eccessivi o query inefficienti. Misura prima e dopo, verifica il tasso di hit e assicurati che l’invalidazione funzioni.
Dopo un ripristino database o una migrazione, svuota la cache oggetti per evitare dati incoerenti. Non programmare flush continui.
Cosa non fare
- non eseguire query DELETE trovate online senza adattarle;
- non svuotare tabelle sconosciute;
- non cancellare tutte le opzioni di plugin disattivati senza verificarle;
- non ottimizzare grandi tabelle durante traffico elevato;
- non installare più plugin di pulizia contemporaneamente;
- non considerare la dimensione totale come unica metrica;
- non aumentare i limiti PHP senza correggere la causa.
Procedura di diagnosi consigliata
- riproduci il problema e annota URL e orario;
- controlla Resource Usage e log;
- misura query e tempi;
- ordina le tabelle per dimensione;
- analizza autoload e code;
- identifica il plugin responsabile;
- prova la correzione su staging;
- esegui backup;
- applica una modifica alla volta;
- misura nuovamente.
Quando aprire un ticket
Apri un ticket se phpMyAdmin va in timeout, il database mostra errori, le risorse restano elevate o non riesci a identificare la query. Indica dominio, URL, orario, operazione, dimensione database, tabelle coinvolte, messaggio completo e modifiche recenti. Non inviare password o dump con dati sensibili se non richiesti attraverso canali sicuri.
Fonti tecniche ufficiali
Domande frequenti
Un database grande è sempre lento?
No. Prestazioni e dimensione sono collegate solo in parte. Indici, query, autoload, hardware e comportamento dei plugin sono spesso più importanti del numero totale di megabyte.
Posso eliminare tutte le revisioni WordPress?
È possibile ridurle, ma prima valuta esigenze editoriali e crea un backup. Limita le revisioni future e usa uno strumento affidabile per quelle esistenti.
Quanto autoload è troppo?
Non esiste una soglia universale. Conta la dimensione, il numero di opzioni, la frequenza delle richieste e il tempo di caricamento. Analizza soprattutto gli elementi più grandi e il plugin proprietario.
Redis risolve un database WordPress lento?
Può ridurre query ripetute, ma non corregge query inefficienti, indici mancanti o tabelle cresciute senza controllo. Serve una misurazione prima e dopo.
È sicuro usare wp db optimize?
Può essere utile, ma va eseguito con backup, nella directory corretta e preferibilmente con poco traffico. Su tabelle grandi può richiedere tempo e risorse.