Come Ottimizzare il Database WordPress nel 2026: Guida Essenziale

Ottimizzare il database WordPress nel 2026 significa individuare ciò che rallenta realmente il sito prima di cancellare dati, modificare tabelle o installare l’ennesimo plugin di pulizia.

Un sito WordPress può utilizzare un hosting veloce, PHP aggiornato, LiteSpeed Cache e storage NVMe, ma continuare a rispondere lentamente se il database contiene opzioni caricate inutilmente, query inefficienti, transient accumulati, revisioni eccessive o tabelle cresciute nel tempo.

Il database contiene una parte fondamentale del sito: articoli, pagine, configurazioni, utenti, dati dei plugin, impostazioni del tema e, nel caso di WooCommerce, anche informazioni relative a prodotti, clienti e ordini.

Per questo motivo ottimizzare il database WordPress non significa semplicemente premere periodicamente un pulsante “Pulisci”.

Il metodo corretto è:

Misura → Analizza → Backup → Correggi → Ottimizza → Verifica

In questa guida vedremo come controllare wp_options, autoload, transient, revisioni, tabelle grandi e query lente, come utilizzare WP-CLI e quando Redis o una object cache persistente possono realmente aiutare.

In breve: perché il database WordPress può rallentare il sito?

WordPress utilizza il database per recuperare molte delle informazioni necessarie a generare una pagina.

Quando il database o il codice che lo interroga diventano inefficienti, il server può dover eseguire più lavoro del necessario.

Tra le cause più comuni troviamo:

• opzioni autoload troppo pesanti;
• plugin che eseguono troppe query;
• query lente o ripetute;
• tabelle molto grandi;
• transient scaduti o mal gestiti;
• revisioni accumulate;
• dati lasciati da plugin non più utilizzati;
• tabelle prive degli indici necessari;
• WooCommerce con grandi quantità di dati;
• cron o attività pianificate che generano continuamente nuove righe;
• assenza di object cache persistente dove sarebbe utile.

La cosa importante è capire che non tutti questi problemi si risolvono allo stesso modo. Per questo motivo il primo passaggio deve essere sempre l’analisi.

Cos’è il database WordPress?

Una normale installazione WordPress utilizza diverse tabelle.

Tra quelle principali troviamo:

• wp_posts;
• wp_postmeta;
• wp_options;
• wp_users;
• wp_usermeta;
• wp_terms;
• wp_termmeta;
• wp_term_taxonomy;
• wp_term_relationships;
• wp_comments;
• wp_commentmeta.

Il prefisso wp_ è quello predefinito e può essere differente sul sito reale.

Plugin e temi possono inoltre creare tabelle personalizzate, righe aggiuntive in wp_options, metadati, transient, eventi cron e configurazioni proprie.

Di conseguenza, due siti WordPress apparentemente simili possono avere database molto diversi.

Prima di ottimizzare il database WordPress: crea un backup

Prima di ottimizzare il database WordPress è necessario disporre di un backup recente e recuperabile.

Questo è particolarmente importante per:

• WooCommerce;
• membership;
• LMS;
• siti con utenti registrati;
• sistemi di prenotazione;
• marketplace;
• portali aziendali.

Un errore sul database può avere effetto immediato sull’intero sito.

La regola deve quindi essere:

backup prima, ottimizzazione dopo.

Per interventi complessi è preferibile utilizzare anche uno staging. Puoi approfondire il flusso operativo nella guida Xlogic dedicata allo staging WordPress con Softaculous.

Database grande e database lento non sono la stessa cosa

Un database di grandi dimensioni non è necessariamente lento.

Allo stesso modo, un database relativamente piccolo può generare problemi se una query viene eseguita centinaia di volte o utilizza una struttura inefficiente.

Le prestazioni dipendono da numerosi elementi:

• struttura delle tabelle;
• numero di righe;
• tipo di query;
• indici;
• frequenza delle richieste;
• dati caricati automaticamente;
• plugin;
• cache;
• risorse disponibili.

Per questo motivo osservare soltanto quanti megabyte occupa il database può portare a una diagnosi sbagliata.

wp_options e autoload: uno dei controlli più importanti

La tabella wp_options contiene numerose impostazioni utilizzate da WordPress, plugin e temi.

Una delle aree più importanti da controllare riguarda le opzioni autoload.

Le opzioni autoload sono configurazioni che WordPress carica automaticamente durante l’esecuzione. Questo comportamento è utile per informazioni utilizzate frequentemente, ma può diventare inefficiente se vengono caricati automaticamente grandi volumi di dati non necessari.

WordPress considera le opzioni autoload un elemento rilevante per le prestazioni. La documentazione ufficiale WordPress sull’ottimizzazione delle prestazioni raccomanda di mantenere sotto controllo la quantità complessiva dei dati caricati automaticamente.

Per ottimizzare il database WordPress in modo efficace è quindi importante individuare le opzioni autoload più pesanti e capire a quale componente appartengono.

Cosa può finire in autoload?

Tra i dati che possono comparire in wp_options troviamo:

• impostazioni dei plugin;
• configurazioni del tema;
• dati temporanei;
• cache applicative;
• informazioni di plugin disinstallati;
• opzioni molto grandi salvate da componenti non ottimizzati.

Il problema non è semplicemente il numero delle righe.

Una singola opzione molto grande può pesare più di centinaia di piccole configurazioni.

Come controllare la dimensione delle opzioni autoload

Il primo controllo può essere effettuato da:

WordPress → Strumenti → Salute del sito

WordPress include un test specifico dedicato alle opzioni autoload.

Per un’analisi più approfondita possiamo utilizzare SQL. Prima di eseguire query manuali identifica sempre il prefisso corretto delle tabelle.

Un esempio diagnostico è:

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto');

Questa query serve a misurare, non modifica i dati.

Individuare le opzioni autoload più grandi

Per trovare le opzioni più pesanti possiamo utilizzare:

SELECT
    option_name,
    LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto')
ORDER BY size_bytes DESC
LIMIT 30;

Il risultato va interpretato con attenzione.

Non bisogna eliminare automaticamente le prime righe della lista.

Per ogni opzione dobbiamo capire:

• quale plugin o tema la utilizza;
• se il componente è ancora presente;
• se l’opzione è necessaria;
• se il dato può essere rigenerato;
• quanto spesso viene utilizzato.

Grande non significa automaticamente inutile.

Non modificare tutti gli autoload in no

Una delle correzioni peggiori sarebbe eseguire una modifica indiscriminata come:

UPDATE wp_options SET autoload='no';

Non va fatto.

Alcune opzioni vengono caricate automaticamente proprio perché sono necessarie frequentemente.

Disabilitare in massa l’autoload può aumentare altre query, compromettere plugin, provocare comportamenti inattesi o peggiorare invece di migliorare le prestazioni.

Per ottimizzare il database WordPress bisogna intervenire selettivamente sui dati realmente identificati come problematici.

Transient WordPress: cosa sono?

I transient sono dati temporanei memorizzati attraverso la Transients API di WordPress.

Vengono utilizzati, ad esempio, per conservare temporaneamente:

• risultati di query;
• risposte di API;
• dati elaborati;
• informazioni che possono essere rigenerate;
• cache applicative.

Un transient dovrebbe quindi essere considerato un dato temporaneo, non un archivio permanente.

Per approfondire il comportamento tecnico puoi consultare la documentazione ufficiale WordPress sulla Transients API.

Eliminare i transient scaduti

Se utilizzi WP-CLI possiamo visualizzare i transient con:

wp transient list

Per eliminare soltanto quelli scaduti:

wp transient delete --expired

Esiste anche:

wp transient delete --all

ma eliminare tutti i transient indiscriminatamente non deve diventare una routine. Molti verranno semplicemente rigenerati dal sito e dai plugin.

Object cache e transient

Quando viene utilizzata una object cache persistente, il comportamento di alcuni dati temporanei può differire rispetto a un sito che utilizza soltanto il database.

WP-CLI permette anche di verificare il tipo di implementazione dei transient:

wp transient type

Questo aiuta a capire se i transient vengono gestiti attraverso il database o tramite una object cache.

Revisioni WordPress

WordPress conserva le revisioni per permettere di recuperare versioni precedenti di articoli e pagine.

È una funzione utile.

Su siti molto attivi, però, le revisioni possono crescere significativamente, soprattutto con numerosi articoli, page builder, molti autori o pagine modificate frequentemente.

Non significa che vadano eliminate tutte.

Una strategia più equilibrata consiste nel limitarne il numero futuro.

Ad esempio, in wp-config.php:

define( 'WP_POST_REVISIONS', 10 );

In questo esempio WordPress conserverà un numero massimo definito di revisioni.

La quantità ideale dipende dal tipo di sito.

Plugin disinstallati e dati residui

Rimuovere un plugin non significa necessariamente eliminare tutti i dati che ha creato.

Possono rimanere:

• tabelle;
• opzioni;
• metadati;
• transient;
• cron;
• log.

Questo può essere intenzionale: alcuni plugin mantengono i dati per permettere una futura reinstallazione.

Prima di cancellare manualmente una tabella o un’opzione bisogna quindi identificare con certezza a quale componente appartenga.

Una tabella sconosciuta non è automaticamente una tabella inutile.

Come trovare le tabelle più grandi

Per capire dove viene utilizzato lo spazio possiamo interrogare information_schema.

Ad esempio:

SELECT
    table_name,
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC;

Questa query mostra le tabelle ordinate per dimensione.

Su un WooCommerce, ad esempio, la distribuzione dei dati può essere molto diversa rispetto a un semplice blog.

wp_postmeta: perché può crescere molto

wp_postmeta contiene metadati associati a post e altri tipi di contenuto.

Può crescere rapidamente nei siti che utilizzano:

• WooCommerce;
• page builder;
• custom fields;
• plugin SEO;
• sistemi complessi di metadati.

Una tabella grande non va comunque ripulita cancellando righe casualmente.

Un metadato può essere associato a prodotti, pagine, ordini, template o configurazioni.

La pulizia deve quindi essere consapevole.

WP-CLI per ottimizzare il database WordPress

WP-CLI può aiutare a ottimizzare il database WordPress e a verificarne lo stato direttamente dal terminale.

Per controllare il database:

wp db check

Per creare un backup SQL:

wp db export backup-prima-ottimizzazione.sql

Conserva il dump in un percorso non pubblicamente scaricabile.

Per ottimizzare le tabelle:

wp db optimize

Il comando è documentato ufficialmente nella pagina WP-CLI: wp db optimize.

Per approfondire la gestione del CMS da terminale puoi leggere anche la guida Xlogic WP-CLI 2026: guida ai comandi WordPress.

Cosa non risolve wp db optimize

Il comando non risolve automaticamente:

• query inefficienti;
• autoload eccessivo;
• plugin mal progettati;
• troppe chiamate al database;
• tabelle inutili;
• mancanza di indici appropriati;
• processi cron problematici.

L’ottimizzazione fisica delle tabelle è soltanto uno dei possibili interventi.

OPTIMIZE TABLE non è una cura universale

Un errore comune è considerare l’ottimizzazione del database come sinonimo di:

OPTIMIZE TABLE ...

Se un plugin esegue una query inefficiente centinaia di volte, ottimizzare fisicamente la tabella potrebbe avere un impatto minimo.

Bisogna prima capire:

quale query è lenta e quale componente la sta generando?

Come individuare query lente

Per un’analisi approfondita possiamo utilizzare strumenti come:

• Query Monitor;
• slow query log di MySQL/MariaDB, quando disponibile;
• strumenti APM;
• profiling;
• log server;
• strumenti del pannello hosting.

Gli elementi da osservare sono:

• durata delle query;
• numero di chiamate;
• query ripetute;
• componente che le genera;
• pagina o operazione interessata.

Una singola query lenta e cento query relativamente piccole possono produrre problemi differenti.

WooCommerce e database WordPress

WooCommerce rende il database molto più dinamico.

Durante il normale utilizzo possono essere continuamente registrati:

• prodotti;
• variazioni;
• ordini;
• clienti;
• pagamenti;
• stock;
• sessioni;
• coupon;
• attività pianificate;
• log.

Per questo motivo, su WooCommerce, ottimizzare il database WordPress richiede maggiore attenzione.

Non bisogna mai sostituire alla cieca il database live con una copia precedente: potrebbero andare persi nuovi ordini, clienti o modifiche registrate dopo la creazione della copia.

Per siti di vendita online puoi approfondire anche le soluzioni Hosting eCommerce Xlogic.

Action Scheduler

WooCommerce e molti plugin utilizzano Action Scheduler per attività in background.

Un numero molto elevato di azioni pendenti o fallite può essere il sintomo di:

• processi che non terminano;
• cron problematici;
• plugin che generano continuamente nuove attività;
• risorse insufficienti;
• errori applicativi.

La soluzione non deve essere automaticamente “svuotare tutto”.

Bisogna identificare perché le azioni si accumulano.

WP-Cron e crescita del database

WP-Cron può essere coinvolto nella crescita continua di alcune tabelle.

Con WP-CLI possiamo visualizzare gli eventi programmati:

wp cron event list

Se un plugin crea ripetutamente attività o genera errori durante la loro esecuzione, eliminare soltanto i dati accumulati non risolve la causa.

Bisogna correggere il processo che continua a generarli.

Redis e object cache persistente

Una object cache persistente consente di conservare in memoria dati che altrimenti dovrebbero essere recuperati ripetutamente dal database.

Questo può ridurre il numero di query necessarie durante alcune richieste.

Tra i sistemi comunemente utilizzati troviamo Redis.

Redis non sostituisce l’ottimizzazione del database

Redis può aiutare, ma non sostituisce il lavoro necessario per ottimizzare il database WordPress.

Redis non corregge:

• query SQL mal progettate;
• plugin inefficienti;
• autoload eccessivo;
• tabelle obsolete;
• processi cron errati;
• grandi quantità di dati inutili.

Il principio corretto è:

correggi la causa → utilizza la cache dove appropriato

e non:

attiva Redis → ignora il database.

Object cache e page cache non sono la stessa cosa

È importante distinguere i livelli di caching.

La page cache può memorizzare una pagina già generata evitando di ricostruirla completamente a ogni visita.

La object cache conserva invece oggetti e dati recuperati durante l’esecuzione di WordPress.

Un sito può beneficiare di entrambe.

Se utilizzi LiteSpeed Cache, quindi, non significa automaticamente che una object cache persistente sia attiva.

Come ottimizzare il database WordPress nel 2026

La checklist seguente permette di ottimizzare il database WordPress con un metodo più sicuro.

1. Crea un backup

Prima di modificare qualsiasi dato:

wp db export backup-prima-ottimizzazione.sql

oppure utilizza il sistema di backup disponibile sull’hosting.

2. Misura

Controlla:

• dimensione complessiva;
• tabelle più grandi;
• autoload;
• transient;
• revisioni;
• query;
• cron;
• attività pianificate.

3. Analizza

Individua le anomalie. Non cancellare ancora nulla.

4. Trova la causa

Chiediti:

quale plugin, tema o processo sta creando questi dati?

5. Correggi selettivamente

Intervieni soltanto sui dati identificati.

6. Ottimizza

Quando necessario:

wp db optimize

7. Verifica

Dopo l’intervento controlla:

• frontend;
• /wp-admin/;
• errori;
• WooCommerce;
• query;
• cron;
• dimensioni delle tabelle;
• performance.

Questo processo è molto più sicuro di una pulizia automatica indiscriminata.

Cosa NON fare per ottimizzare il database WordPress

Non eliminare tutte le opzioni autoload

Molte sono necessarie.

Non impostare tutti gli autoload su no

Potresti aumentare le query o compromettere il funzionamento del sito.

Non cancellare tabelle che non riconosci

Prima identifica con certezza il componente che le utilizza.

Non eliminare tutti i transient continuamente

Molti vengono rigenerati e l’operazione potrebbe non risolvere alcun problema reale.

Non cancellare indiscriminatamente postmeta

I dati potrebbero essere necessari a prodotti, pagine, ordini e plugin.

Non importare un database vecchio sopra WooCommerce live

Potresti perdere ordini e clienti recenti.

Non considerare wp db optimize una soluzione universale

Ottimizza le tabelle, ma non corregge automaticamente query applicative inefficienti.

Non intervenire senza backup

Una singola query SQL errata può modificare migliaia di record.

Quanto spesso bisogna ottimizzare il database?

Non esiste una frequenza valida per tutti.

Un blog con pochi aggiornamenti ha esigenze diverse da un WooCommerce, un portale, una community, un LMS o un sito con molte operazioni giornaliere.

È preferibile basare la manutenzione su segnali reali:

• crescita anomala;
• peggioramento delle prestazioni;
• Site Health;
• query lente;
• errori;
• plugin rimossi;
• migrazioni;
• forte aumento del traffico.

Non serve effettuare pulizie invasive ogni settimana senza motivo.

Database WordPress su hosting Xlogic

Un database efficiente è soltanto una parte dello stack WordPress.

Le prestazioni complessive dipendono dall’interazione tra:

WordPress → plugin → PHP → database → cache → storage → server

Su un ambiente hosting moderno, tecnologie come storage SSD NVMe, PHP aggiornato, LiteSpeed e sistemi di caching possono ridurre significativamente i tempi di risposta.

Ma un plugin che genera query inefficienti continuerà comunque a richiedere risorse.

Per questo motivo l’ottimizzazione deve partire dall’applicazione e dai dati reali. Per progetti WordPress puoi consultare anche le soluzioni Hosting WordPress Xlogic.

Domande frequenti sull’ottimizzazione del database WordPress

Come capire se devo ottimizzare il database WordPress?

Non basarti soltanto sulla dimensione. Controlla Site Health, opzioni autoload, tabelle più grandi, query lente, transient, cron e crescita del database nel tempo.

Quanto devono pesare le opzioni autoload?

WordPress utilizza un controllo specifico in Site Health per segnalare quando il carico delle opzioni autoload può diventare problematico. È comunque una soglia diagnostica e non un valore magico valido per ogni sito.

Posso cancellare tutte le opzioni autoload?

No. Molte sono necessarie a WordPress, temi e plugin e devono essere analizzate singolarmente.

Come elimino i transient scaduti?

Con WP-CLI:

wp transient delete --expired

Come verifico se i transient usano il database o una object cache?

Puoi utilizzare:

wp transient type

Come controllo il database con WP-CLI?

Puoi iniziare con:

wp db check

Come creo un backup SQL?

Con:

wp db export backup.sql

Evita di lasciare il dump in una directory pubblicamente accessibile.

Come ottimizzo le tabelle?

Puoi utilizzare:

wp db optimize

Redis rende inutile ottimizzare il database WordPress?

No. Redis può ridurre alcuni accessi ripetitivi al database, ma non corregge query inefficienti, autoload eccessivo o dati inutili.

Le revisioni devono essere eliminate?

Non necessariamente. Sono utili. Se diventano eccessive è possibile limitarne il numero futuro tramite WP_POST_REVISIONS.

Un database molto grande è necessariamente lento?

No. Le prestazioni dipendono anche da query, indici, cache, frequenza degli accessi e struttura dei dati.

Posso usare un plugin di pulizia?

Sì, ma devi sapere quali dati verranno eliminati. Un’interfaccia grafica non rende automaticamente sicura un’operazione distruttiva.

Conclusioni

Ottimizzare il database WordPress significa prima di tutto capire come vengono utilizzati i dati.

Non esiste un pulsante universale capace di correggere automaticamente autoload, transient, revisioni, query lente, plugin inefficienti, WooCommerce, cron e tabelle cresciute nel tempo.

Il workflow consigliato resta:

Misura → Analizza → Backup → Correggi → Ottimizza → Verifica

Le aree da controllare con maggiore attenzione sono:

• wp_options;
• autoload;
• transient;
• revisioni;
• tabelle grandi;
• wp_postmeta;
• query lente;
• cron;
• WooCommerce;
• object cache.

WP-CLI può semplificare numerose attività di controllo e manutenzione, mentre Redis e altri sistemi di object caching possono ridurre alcuni accessi ripetitivi al database.

Ma nessuno strumento sostituisce una diagnosi corretta.

Un database efficiente non è necessariamente quello più piccolo: è quello che contiene i dati necessari e permette a WordPress di recuperarli senza lavoro inutile.