Database WordPress lento: diagnosi e ottimizzazione

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

  1. crea un backup recente;
  2. verifica che il backup sia scaricabile o ripristinabile;
  3. annota prefisso e nome del database;
  4. esegui le operazioni in un periodo con poco traffico;
  5. non lavorare contemporaneamente su file e database;
  6. prova prima su staging quando il sito è critico;
  7. 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 optimize

Esegui 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

  1. riproduci il problema e annota URL e orario;
  2. controlla Resource Usage e log;
  3. misura query e tempi;
  4. ordina le tabelle per dimensione;
  5. analizza autoload e code;
  6. identifica il plugin responsabile;
  7. prova la correzione su staging;
  8. esegui backup;
  9. applica una modifica alla volta;
  10. 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.

Database WordPress lento: diagnosi e ottimizzazione ultima modifica: 2026-08-01T18:25:52+02:00 da Team tecnico Xlogic

Ti è piaciuto questo Post?