Procedura corretta: controlla il peso dell’autoload in wp_options con la query SQL nella sezione 1 — sopra 3 MB è quasi certamente la causa del rallentamento. Poi backup del database, poi si opera nell’ordine seguente: transient scaduti, revisioni eccessive dopo aver impostato il limite in wp-config(.)php, OPTIMIZE TABLE sulle tabelle con overhead. L’autoload di wp_options si tratta per ultimo, con attenzione. WP-Optimize copre la manutenzione ordinaria ma non l’analisi dell’autoload — quella richiede phpMyAdmin e le query descritte qui.
Il sito ha iniziato a rallentare. Non in modo drammatico; impercettibilmente, nel corso di settimane. Il TTFB è salito da 300ms a 700ms. Google PageSpeed ha abbassato il punteggio. Il traffico organico ha smesso di crescere. Hai già pulito la cache, ottimizzato le immagini, aggiornato i plugin. Il problema rimane.
Se hai il monitoraggio uptime WordPress attivo, probabilmente hai già visto il TTFB salire settimane prima che il problema diventasse evidente. Questa guida ti dice dove andare a cercare e come intervenire nell’ordine corretto.
Il vero problema non sono le revisioni: wp_options e l'autoload
Ogni volta che WordPress carica una pagina, esegue una query per recuperare tutti i record della tabella wp_options con autoload = yes. Non alcuni: tutti. Su un’installazione nuova sono poche decine di record. Su un sito attivo da anni con plugin cambiati nel tempo, possono essere migliaia.
Il problema nasce quando un plugin viene disinstallato senza fare pulizia dei propri dati. Le opzioni rimangono nella tabella, con autoload attivo, e vengono caricate ad ogni richiesta anche se nessun plugin le usa più. Ho visto siti con oltre 5 MB di dati in autoload: caricati integralmente ad ogni pageview, prima che WordPress faccia qualsiasi altra cosa.
Su siti con Redis Object Cache o Memcached attivo, parte del problema può sembrare meno evidente perché molte query vengono servite dalla cache persistente invece che dal database. Ma un autoload eccessivo resta comunque un segnale di manutenzione trascurata: quando la cache viene svuotata o rigenerata, WordPress deve comunque caricare tutti quei dati inutili.
Per verificare il peso dell’autoload sul tuo sito, esegui questa query in phpMyAdmin:
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload = 'yes';
- Sotto 1 MB: nessun problema.
- Tra 1 MB e 3 MB: vale la pena pulire.
- Sopra 3 MB: il database è quasi certamente una delle cause del rallentamento.
Per identificare i record più pesanti e probabilmente orfani:
SELECT option_name, LENGTH(option_value) as size, autoload FROM wp_options WHERE autoload = 'yes' ORDER BY size DESC LIMIT 20;
I risultati da cercare: opzioni con nomi che non corrispondono a nessun plugin attualmente installato, transient con prefisso _transient_ o _site_transient_, dati di sessione o cache di plugin rimossi.
Alcuni record compaiono spesso nei database WordPress molto appesantiti: transient WooCommerce lasciati da sessioni vecchie, cache di page builder come Elementor, dati SEO di plugin sostituiti nel tempo oppure record molto grandi come rewrite_rules. Non significa che vadano eliminati automaticamente; significa che meritano verifica.
Attenzione prima di eliminare: non eliminare record da wp_options senza sapere a cosa appartengono. Alcuni record con nomi non immediatamente riconoscibili sono necessari per il funzionamento di WordPress. Se non sei sicuro, cambia autoload da ‘yes‘ a ‘no‘ invece di eliminare; il record rimane ma non viene più caricato ad ogni richiesta.
Come diagnosticare il database prima di toccare qualcosa
Fai un backup del database. Non il backup dell’intero sito: basta un dump tramite phpMyAdmin (Esporta → Formato SQL → Scarica). Occupa pochi MB e richiede due minuti. È l’unica operazione che non si può fare dopo.
Con accesso a phpMyAdmin, la sezione Stato del database mostra le tabelle con overhead: spazio frammentato che occupa disco senza contenere dati utili. L’overhead si accumula dopo molte operazioni di inserimento e cancellazione ed è normale, ma va pulito periodicamente.
Query per avere un quadro completo di tutte le tabelle e il loro peso:
SELECT table_name, table_rows, ROUND(data_length/1024/1024, 2) AS data_mb, ROUND(data_free/1024/1024, 2) AS overhead_mb FROM information_schema.tables WHERE table_schema = DATABASE() ORDER BY data_free DESC;
Le tabelle con overhead_mb alto sono quelle da ottimizzare con OPTIMIZE TABLE. Le tabelle con data_mb inaspettatamente alto rispetto al contenuto atteso meritano un’analisi più approfondita.
Se vuoi capire quali plugin stanno generando più query o query particolarmente lente, Query Monitor è il plugin più utile da installare temporaneamente. Non sostituisce phpMyAdmin: lavora a un livello diverso. Mostra query duplicate, hook lenti, chiamate AJAX pesanti e componenti che interrogano il database in modo inefficiente.
Quando i dati temporanei non vengono più rimossi
I transient sono dati temporanei che WordPress e i plugin usano per memorizzare risultati di query costose: feed RSS, dati di API esterne, calcoli complessi. Hanno una scadenza, dopo la quale dovrebbero essere rimossi automaticamente.
Dovrebbero: perché WordPress li rimuove solo quando vengono richiesti dopo la scadenza, non con un processo attivo. Su siti con traffico irregolare o con molti plugin che usano i transient, questi dati scaduti si accumulano in wp_options occupando spazio e contribuendo al peso dell’autoload.
Per rimuovere tutti i transient scaduti con una singola query SQL:
DELETE FROM wp_options WHERE option_name LIKE '%_transient_%' AND option_name NOT LIKE '%_transient_timeout_%';
WooCommerce: le sessioni carrello
Su installazioni WooCommerce, la tabella che tende a gonfiarsi di più non è wp_options ma wp_woocommerce_sessions. Ogni sessione utente che non completa l’acquisto lascia un record nella tabella; su e-commerce con traffico continuativo questi record si accumulano rapidamente.
Da dashboard WordPress: WooCommerce → Stato → Strumenti → Elimina sessioni cliente. Attenzione: questa operazione svuota anche i carrelli salvati degli utenti loggati; pianificarla nelle ore di minor traffico.
WP-Optimize esegue la pulizia dei transient automaticamente. Per programmare la pulizia automatica delle sessioni WooCommerce, il cron job è lo strumento corretto: un argomento che approfondisco in un articolo dedicato.
Le revisioni degli articoli occupano spazio. Ma raramente sono il vero problema
WordPress salva una revisione ogni volta che salvi un articolo. Su un blog attivo da anni con decine di articoli modificati frequentemente, le revisioni possono rappresentare migliaia di record in wp_posts. Il problema reale non è il peso sul disco; è il numero di record che il database deve scorrere nelle query che coinvolgono wp_posts.
Limitare le revisioni future
Aggiungi questa riga in wp-config(.)php prima della riga /* That’s all, stop editing! */:
define('WP_POST_REVISIONS', 3);3 revisioni per articolo è un valore ragionevole: abbastanza per tornare indietro in caso di errore, abbastanza poche da non lasciare crescere la tabella indefinitamente. Il valore 0 disabilita le revisioni completamente, ma rimuove una rete di sicurezza utile senza un beneficio proporzionale.
Eliminare le revisioni esistenti
Per rimuovere tutte le revisioni accumulate nel tempo:
DELETE FROM wp_posts WHERE post_type = 'revision'; DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT ID FROM wp_posts);
Esegui le due query nell’ordine indicato. La seconda rimuove i metadati orfani rimasti dopo l’eliminazione delle revisioni; va eseguita dopo la prima, non prima.
Ottimizzare le tabelle: OPTIMIZE TABLE e overhead
Dopo aver eliminato dati (revisioni, transient, spam, post nel cestino), le tabelle contengono spazio frammentato che MySQL non riutilizza automaticamente. OPTIMIZE TABLE riorganizza la struttura fisica della tabella recuperando quello spazio.
Da phpMyAdmin, seleziona tutte le tabelle WordPress, poi dal menu a tendina in basso scegli “Ottimizza tabella”. In alternativa, da WP-CLI:
wp db optimize
Su tabelle InnoDB (il tipo predefinito nelle installazioni WordPress moderne), OPTIMIZE TABLE equivale a ricreare la tabella: può richiedere più tempo su tabelle grandi. Su siti in produzione con traffico alto, pianifica l’operazione nelle ore di minor utilizzo.
Frequenza: una volta al mese è sufficiente per la maggior parte dei siti. Per e-commerce WooCommerce con molte transazioni giornaliere, che generano molti inserimenti e cancellazioni in wp_woocommerce_sessions e nelle tabelle degli ordini, può valere la pena farlo settimanalmente.
WP-Optimize: quando usarlo e quando non basta
WP-Optimize automatizza la pulizia delle revisioni, dei transient, dei commenti spam, dei post nel cestino e l’ottimizzazione delle tabelle. Per la manutenzione ordinaria è uno strumento solido: 1 milione di installazioni attive, aggiornato regolarmente, gratuito nel piano base.
Quello che WP-Optimize non fa: non analizza il peso dell’autoload in wp_options e non identifica i record orfani da plugin disinstallati. Per questo serve la diagnosi manuale descritta nella prima sezione.
Configurazione consigliata
- Abilita la pulizia automatica settimanale per revisioni e transient.
- Mantieni almeno 2-3 revisioni per articolo; non azzerare completamente.
- Esegui l’ottimizzazione delle tabelle mensile, non settimanale; su tabelle grandi è un’operazione pesante.
- Non abilitare la cache di WP-Optimize se hai già WP Rocket, W3 Total Cache o LiteSpeed Cache attivo; i due sistemi di cache interferiscono.
WP-CLI: l’alternativa da riga di comando
Per chi ha accesso SSH al server, WP-CLI è più veloce e più preciso di phpMyAdmin per le operazioni di manutenzione del database. I comandi principali:
wp transient delete --expired # rimuove i transient scaduti wp post delete $(wp post list --post_type=revision --format=ids) # elimina revisioni wp db optimize # OPTIMIZE TABLE su tutte le tabelle wp db size # mostra dimensione tabelle
WP-CLI è particolarmente utile quando si gestiscono più siti WordPress: permette di automatizzare la manutenzione con script shell e di integrare le operazioni in pipeline di deployment.
Se il database mostra overhead elevato, il sito è lento nonostante le ottimizzazioni standard, o vuoi una revisione completa della configurazione senza rischiare di rompere qualcosa. Se vuoi capire cosa include una manutenzione WordPress corretta, trovi tutte le guide nella sezione dedicata alla manutenzione ordinaria del sito WordPress.
In sintesi
Il rallentamento del database WordPress raramente viene dalle revisioni. Quasi sempre viene da wp_options con troppi dati in autoload: record lasciati da plugin disinstallati che vengono caricati ad ogni richiesta anche se non servono più. Controlla il peso dell’autoload con la query SQL nella prima sezione; sopra 3 MB è quasi certamente una delle cause del problema.
La pulizia ha un ordine preciso: diagnosi prima, backup obbligatorio, poi si opera. Prima i transient scaduti; sicuri da eliminare. Poi le revisioni eccessive, dopo aver impostato il limite in wp-config(.)php per non farne ricrescere di nuove. Poi OPTIMIZE TABLE sulle tabelle con overhead. L’autoload di wp_options si tratta per ultimo, con attenzione, cambiando autoload da ‘yes’ a ‘no’ invece di eliminare quando non sei sicuro dell’origine del record.
WP-Optimize copre la manutenzione ordinaria. WP-CLI è più preciso se hai accesso SSH. Nessuno dei due copre l’analisi dell’autoload; quella richiede phpMyAdmin e le query descritte qui.
Non tutto però dipende da WordPress. Database lenti possono dipendere anche da hosting condivisi sovraccarichi, dischi lenti o configurazioni MySQL/MariaDB molto conservative. Se il database è già pulito ma il TTFB rimane alto, il collo di bottiglia potrebbe essere l’infrastruttura del server e non il sito stesso.
Frequenza: mensile per la pulizia standard. Trimestrale per l’analisi di wp_options. Prima di ogni aggiornamento importante: sempre un backup del database, sempre.
Domande frequenti (FAQ)
Ottimizzare il database rallenta il sito durante l'operazione?
OPTIMIZE TABLE su tabelle grandi può richiedere qualche minuto e aumentare il carico del server durante l’esecuzione. Su hosting condivisi, pianifica l’operazione nelle ore di minor traffico. WP-Optimize permette di schedulare le operazioni in orari specifici. La pulizia dei transient e delle revisioni è invece quasi istantanea anche su database grandi.
Quante revisioni è ragionevole tenere per articolo?
3-5 revisioni è il range consigliato. Abbastanza per tornare a una versione precedente in caso di errore di modifica, abbastanza poche da non lasciare crescere la tabella wp_posts indefinitamente. Il valore 0 rimuove una protezione utile; non è raccomandato a meno che non si abbia un sistema di versionamento alternativo.
Cos'è l'overhead del database e quando è un problema?
L’overhead è spazio frammentato nelle tabelle MySQL che occupa disco senza contenere dati utili. Si accumula dopo molte operazioni di inserimento e cancellazione. Diventa un problema quando supera il 10-20% della dimensione della tabella, rallentando le query. OPTIMIZE TABLE lo risolve recuperando quello spazio. Piccole quantità di overhead (pochi MB) non impattano le performance in modo misurabile.
Posso usare WP-CLI per ottimizzare il database invece di phpMyAdmin?
wp transient delete –expired per rimuovere i transient scaduti, wp db optimize per eseguire OPTIMIZE TABLE su tutte le tabelle. Richiede accesso SSH al server. Per eliminare le revisioni via WP-CLI: wp post delete $(wp post list –post_type=revision –format=ids).
Come faccio a sapere se il database è la causa del rallentamento?
Il segnale più affidabile è un TTFB (Time To First Byte) elevato: sopra 800ms su una pagina senza cache. Il TTFB misura il tempo che il server impiega a generare la risposta, il che include le query al database. Puoi misurarlo con Google PageSpeed Insights o con gli strumenti per sviluppatori del browser (Network → prima richiesta → Time). Se il TTFB è alto ma il server ha risorse sufficienti, il database è quasi sempre la causa.
Su WooCommerce o siti membership il problema spesso si vede prima nel backend che nel frontend: ordini lenti da aprire, ricerca prodotti macchinosa, dashboard amministrativa che impiega secondi a caricarsi. Quando il database cresce senza manutenzione, il rallentamento non colpisce solo PageSpeed; rallenta operazioni quotidiane che hanno impatto diretto su vendite e tempi operativi.
La pulizia del database, la gestione dell’autoload e l’ottimizzazione delle tabelle rientrano in un piano di assistenza tecnica del sito WordPress attivo — chi mi affida la gestione del sito a livello professionale non deve preoccuparsene.