{"id":743,"date":"2026-02-23T09:00:00","date_gmt":"2026-02-23T08:00:00","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/pulire-database-wordpress-velocizzare\/"},"modified":"2026-02-18T18:04:18","modified_gmt":"2026-02-18T17:04:18","slug":"pulire-database-wordpress-velocizzare","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/pulire-database-wordpress-velocizzare\/","title":{"rendered":"Come Pulisco il Database WordPress per Velocizzare il Sito: La Mia Procedura"},"content":{"rendered":"<p>Se gestisci un sito WordPress da qualche anno, ti sarai accorto che con il passare del tempo diventa sempre pi\u00f9 lento. Le pagine impiegano pi\u00f9 secondi a caricarsi, il backend si trascina e le query al database sembrano non finire mai. Il colpevole, nella maggior parte dei casi, non \u00e8 il tema o i plugin: \u00e8 il <strong>database<\/strong>. Un database WordPress che non viene mai pulito accumula una quantit\u00e0 impressionante di dati inutili: revisioni di articoli, auto-draft, transient scaduti, metadati orfani, commenti spam e tabelle abbandonate da plugin disinstallati. Ho visto database di siti con poche centinaia di articoli pesare oltre 500 MB, quando avrebbero dovuto occuparne 30. In questa guida ti mostro esattamente la procedura che seguo io, Dario Iannascoli, per ripulire il database WordPress e riportare il sito a prestazioni ottimali.<\/p>\n<p>Questa non \u00e8 una guida teorica. \u00c8 il risultato di anni di esperienza diretta nella manutenzione di decine di siti WordPress, dal piccolo blog personale al portale aziendale con migliaia di pagine. La procedura che descrivo qui l&#8217;ho affinata nel tempo, partendo da errori che mi sono costati ore di lavoro e qualche notte insonne. La regola fondamentale che ho imparato \u00e8 semplice: <strong>prima fai il backup, poi tocchi il database<\/strong>. Nessuna eccezione. Vedrai che seguendo i miei passaggi riuscirai a ridurre drasticamente le dimensioni del database, abbattere i tempi di risposta delle query e, in definitiva, velocizzare l&#8217;intero sito. Ti mostrer\u00f2 sia l&#8217;approccio con plugin sia le query SQL manuali per chi preferisce avere il controllo totale. Partiamo.<\/p>\n<h2>Cosa Gonfia il Database WordPress: I Nemici delle Prestazioni<\/h2>\n<p>Per capire come pulire il database, devi prima sapere cosa lo sporca. WordPress, per sua natura, tende ad accumulare dati che non servono pi\u00f9. Il problema \u00e8 che non li elimina mai da solo. Ecco i principali responsabili del <strong>bloat del database<\/strong>, quelli che trovo sistematicamente in ogni installazione che analizzo:<\/p>\n<ul>\n<li><strong>Revisioni degli articoli (post revisions)<\/strong> &#8211; Ogni volta che salvi un articolo, WordPress crea una revisione nella tabella <strong>wp_posts<\/strong>. Un articolo modificato 50 volte avr\u00e0 50 revisioni. Moltiplica per centinaia di articoli e capisci il problema. Ho trovato siti con oltre 20.000 revisioni che occupavano pi\u00f9 spazio degli articoli stessi. WordPress non impone un limite di default, quindi le revisioni crescono senza controllo.<\/li>\n<li><strong>Auto-draft e articoli cestinati<\/strong> &#8211; WordPress salva automaticamente una bozza ogni 60 secondi mentre scrivi. Questi <strong>auto-draft<\/strong> restano nel database anche quando l&#8217;articolo \u00e8 stato pubblicato. Allo stesso modo, gli articoli nel cestino non vengono eliminati definitivamente finch\u00e9 non li svuoti manualmente. Spesso restano l\u00ec per mesi o anni.<\/li>\n<li><strong>Transient scaduti<\/strong> &#8211; I <strong>transient<\/strong> sono dati temporanei che WordPress e i plugin salvano nella tabella <strong>wp_options<\/strong> per velocizzare operazioni ripetitive. Il problema \u00e8 che molti transient scaduti non vengono rimossi automaticamente. Col tempo si accumulano a migliaia, rallentando ogni query sulla tabella wp_options, che \u00e8 una delle pi\u00f9 consultate.<\/li>\n<li><strong>Metadati orfani<\/strong> &#8211; Quando elimini un articolo, un commento o un utente, WordPress non sempre cancella i relativi metadati dalle tabelle <strong>wp_postmeta<\/strong>, <strong>wp_commentmeta<\/strong> e <strong>wp_usermeta<\/strong>. Questi record orfani occupano spazio e rallentano le JOIN nelle query. Ho visto tabelle wp_postmeta con milioni di righe, di cui il 40% erano orfane.<\/li>\n<li><strong>Commenti spam<\/strong> &#8211; Se usi Akismet o un altro sistema antispam, i commenti marcati come spam restano nel database nella tabella <strong>wp_comments<\/strong> insieme ai relativi metadati. Un sito popolare pu\u00f2 accumulare decine di migliaia di commenti spam in pochi mesi se non li elimini regolarmente.<\/li>\n<li><strong>Tabelle orfane di plugin disinstallati<\/strong> &#8211; Questo \u00e8 uno dei problemi pi\u00f9 subdoli. Molti plugin creano le proprie tabelle nel database durante l&#8217;installazione, ma <strong>non le rimuovono<\/strong> quando li disinstalli. Dopo anni di prove e cambi di plugin, il database si riempie di tabelle inutili che nessuno usa pi\u00f9. Ho trovato database con 30-40 tabelle orfane lasciate da plugin rimossi anni prima.<\/li>\n<li><strong>Dati nella tabella wp_options con autoload<\/strong> &#8211; La tabella wp_options viene caricata quasi interamente in memoria a ogni richiesta, specialmente le righe con <strong>autoload=yes<\/strong>. Plugin mal scritti inseriscono grandi quantit\u00e0 di dati con autoload attivo, rallentando ogni singolo caricamento di pagina. Questa \u00e8 spesso la causa nascosta di lentezze inspiegabili.<\/li>\n<\/ul>\n<h2>Backup del Database: Il Passo Zero Obbligatorio<\/h2>\n<p>Non mi stancher\u00f2 mai di ripeterlo: <strong>prima di toccare qualsiasi cosa nel database, fai un backup completo<\/strong>. Non importa quanto sei esperto, non importa quanto sei sicuro della query che stai per eseguire. Un errore in una DELETE senza WHERE pu\u00f2 cancellare l&#8217;intero contenuto di una tabella in un istante. Ecco come faccio io il backup prima di ogni operazione di pulizia:<\/p>\n<ol>\n<li><strong>Backup con mysqldump da riga di comando<\/strong> &#8211; Il metodo pi\u00f9 affidabile. Accedo al server via SSH ed eseguo: <strong>mysqldump -u nome_utente -p nome_database &gt; backup_pre_pulizia_$(date +%Y%m%d).sql<\/strong>. Questo crea un file SQL completo con struttura e dati di tutte le tabelle. Verifico sempre che il file abbia una dimensione coerente e che termini con il dump delle tabelle, non con un errore.<\/li>\n<li><strong>Backup tramite phpMyAdmin<\/strong> &#8211; Se non hai accesso SSH, apri phpMyAdmin dal pannello di controllo hosting, seleziona il database WordPress, clicca su <strong>Esporta<\/strong>, scegli il metodo <strong>Personalizzato<\/strong>, assicurati che tutte le tabelle siano selezionate, formato SQL, e clicca <strong>Esegui<\/strong>. Salva il file .sql sul tuo computer locale.<\/li>\n<li><strong>Backup con plugin WordPress<\/strong> &#8211; Se non hai accesso al database direttamente, usa un plugin come <strong>UpdraftPlus<\/strong> o <strong>All-in-One WP Migration<\/strong>. Vai in Impostazioni &gt; UpdraftPlus, clicca su <strong>Backup adesso<\/strong> e assicurati che sia selezionata l&#8217;opzione Database. Il backup verr\u00e0 salvato nella cartella wp-content\/updraft del tuo server.<\/li>\n<li><strong>Verifica del backup<\/strong> &#8211; Non mi fido mai di un backup che non ho verificato. Creo un database di test, importo il backup con <strong>mysql -u utente -p database_test &lt; backup.sql<\/strong> e controllo che le tabelle ci siano tutte e contengano dati. Solo dopo questa verifica procedo con la pulizia. Questa fase richiede cinque minuti ma pu\u00f2 salvarti ore di disperazione.<\/li>\n<li><strong>Conservazione del backup<\/strong> &#8211; Tengo il backup della pre-pulizia per almeno 30 giorni, sia sul server sia scaricato in locale. Lo etichetto chiaramente con la data e il motivo, ad esempio <strong>backup_pre_pulizia_database_20260207.sql<\/strong>. Mai sovrascrivere un backup con uno pi\u00f9 recente finch\u00e9 non sei certo che tutto funzioni correttamente dopo la pulizia.<\/li>\n<\/ol>\n<h2>Pulizia con Plugin: WP-Optimize e Advanced Database Cleaner<\/h2>\n<p>Per chi preferisce un approccio guidato e sicuro, i plugin di pulizia database rappresentano la scelta migliore. Ne ho provati molti nel corso degli anni e i due che consiglio sono <strong>WP-Optimize<\/strong> e <strong>Advanced Database Cleaner<\/strong>. Entrambi fanno un ottimo lavoro, ma con approcci leggermente diversi. Ecco come li uso nella mia procedura quotidiana di manutenzione:<\/p>\n<ol>\n<li><strong>Installazione di WP-Optimize<\/strong> &#8211; Vai in Plugin &gt; Aggiungi nuovo, cerca <strong>WP-Optimize<\/strong> e installalo. Questo plugin \u00e8 sviluppato dallo stesso team di UpdraftPlus ed \u00e8 estremamente affidabile. Dopo l&#8217;attivazione, trovi il menu WP-Optimize nella sidebar di WordPress. La sezione <strong>Database<\/strong> ti mostra immediatamente quanti dati inutili ha rilevato.<\/li>\n<li><strong>Eseguire la pulizia con WP-Optimize<\/strong> &#8211; Nella scheda Database, trovi un elenco di categorie: revisioni, auto-draft, commenti spam, commenti cestinati, transient scaduti, tabelle non ottimizzate. Per ogni categoria vedi il numero di elementi trovati. Seleziona tutte le categorie che vuoi pulire e clicca <strong>Esegui ottimizzazione<\/strong>. Ti consiglio di procedere una categoria alla volta la prima volta, verificando dopo ogni passaggio che il sito funzioni correttamente.<\/li>\n<li><strong>Advanced Database Cleaner per le tabelle orfane<\/strong> &#8211; Dove WP-Optimize eccelle nella pulizia dei dati, <strong>Advanced Database Cleaner<\/strong> \u00e8 superiore nel rilevamento delle <strong>tabelle orfane<\/strong>. Dopo l&#8217;installazione, vai nella sezione Tables e il plugin ti mostrer\u00e0 quali tabelle non appartengono a nessun plugin attivo. Controlla ogni tabella segnalata prima di eliminarla: a volte tabelle apparentemente orfane sono usate da temi o da codice personalizzato nel functions.php.<\/li>\n<li><strong>Pulizia della tabella wp_options<\/strong> &#8211; WP-Optimize ha una funzione specifica per analizzare la tabella wp_options e identificare i transient scaduti e le righe con <strong>autoload=yes<\/strong> che occupano troppo spazio. Nella versione premium puoi anche gestire l&#8217;autoload, ma nella versione gratuita la pulizia dei transient \u00e8 gi\u00e0 disponibile e molto efficace. Ho visto riduzioni della tabella wp_options da 50 MB a 2 MB dopo questa operazione.<\/li>\n<li><strong>Ottimizzazione delle tabelle<\/strong> &#8211; Dopo la pulizia dei dati, \u00e8 fondamentale eseguire l&#8217;<strong>OPTIMIZE TABLE<\/strong> su tutte le tabelle. WP-Optimize lo fa con un click nella sezione dedicata. Questa operazione riorganizza fisicamente i dati nelle tabelle, recuperando lo spazio lasciato dai record eliminati e migliorando le prestazioni delle query. \u00c8 come deframmentare un disco rigido: i dati ci sono ancora, ma sono organizzati meglio.<\/li>\n<\/ol>\n<h2>Query SQL Manuali per la Pulizia: Il Controllo Totale<\/h2>\n<p>Quando devo fare una pulizia chirurgica o quando lavoro su server dove non posso installare plugin, ricorro alle <strong>query SQL manuali<\/strong>. Questo approccio richiede pi\u00f9 attenzione ma offre un controllo totale su cosa viene eliminato. Accedo a phpMyAdmin o uso la riga di comando MySQL e eseguo le seguenti query. Ricorda: <strong>backup prima di tutto<\/strong>. Ogni query va testata prima con una SELECT per verificare cosa verr\u00e0 eliminato, poi convertita in DELETE.<\/p>\n<ol>\n<li><strong>Eliminare tutte le revisioni degli articoli<\/strong> &#8211; Questa \u00e8 la query che uso pi\u00f9 frequentemente. Prima verifico quante revisioni ci sono: <strong>SELECT COUNT(*) FROM wp_posts WHERE post_type = &#8216;revision&#8217;;<\/strong>. Poi elimino le revisioni e i relativi metadati: <strong>DELETE a, b, c FROM wp_posts a LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id) WHERE a.post_type = &#8216;revision&#8217;;<\/strong>. Questa query elimina revisioni, relazioni con le tassonomie e metadati in un colpo solo.<\/li>\n<li><strong>Eliminare gli auto-draft<\/strong> &#8211; Gli auto-draft sono bozze automatiche che WordPress crea durante la scrittura: <strong>DELETE FROM wp_posts WHERE post_status = &#8216;auto-draft&#8217;;<\/strong>. Segui con <strong>DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT ID FROM wp_posts);<\/strong> per rimuovere i metadati orfani risultanti. Questa seconda query \u00e8 fondamentale e va eseguita dopo ogni eliminazione di record dalla tabella wp_posts.<\/li>\n<li><strong>Eliminare i transient scaduti<\/strong> &#8211; I transient scaduti nella tabella wp_options si eliminano con: <strong>DELETE FROM wp_options WHERE option_name LIKE &#8216;_transient_timeout_%&#8217; AND option_value &lt; UNIX_TIMESTAMP();<\/strong> seguita da <strong>DELETE FROM wp_options WHERE option_name LIKE &#8216;_transient_%&#8217; AND option_name NOT LIKE &#8216;_transient_timeout_%&#8217; AND option_name NOT IN (SELECT REPLACE(option_name, &#8216;_transient_timeout_&#8217;, &#8216;_transient_&#8217;) FROM (SELECT option_name FROM wp_options WHERE option_name LIKE &#8216;_transient_timeout_%&#8217;) AS t);<\/strong>. In alternativa, una versione pi\u00f9 semplice: <strong>DELETE FROM wp_options WHERE option_name LIKE &#8216;%_transient_%&#8217;;<\/strong> che elimina tutti i transient, anche quelli non scaduti (verranno ricreati automaticamente).<\/li>\n<li><strong>Eliminare i commenti spam e cestinati<\/strong> &#8211; Per i commenti spam: <strong>DELETE FROM wp_comments WHERE comment_approved = &#8216;spam&#8217;;<\/strong>. Per i commenti nel cestino: <strong>DELETE FROM wp_comments WHERE comment_approved = &#8216;trash&#8217;;<\/strong>. Dopo entrambe le operazioni, pulisci i metadati orfani: <strong>DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);<\/strong>. Ho gestito un sito che aveva accumulato 180.000 commenti spam in due anni: la sola eliminazione di questi ha ridotto il database di 120 MB.<\/li>\n<li><strong>Eliminare i metadati orfani<\/strong> &#8211; Questa \u00e8 la pulizia pi\u00f9 importante dopo le eliminazioni precedenti. Per i post meta: <strong>DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON pm.post_id = p.ID WHERE p.ID IS NULL;<\/strong>. Per i comment meta: <strong>DELETE cm FROM wp_commentmeta cm LEFT JOIN wp_comments c ON cm.comment_id = c.comment_id WHERE c.comment_id IS NULL;<\/strong>. Per le relazioni con le tassonomie: <strong>DELETE tr FROM wp_term_relationships tr LEFT JOIN wp_posts p ON tr.object_id = p.ID WHERE p.ID IS NULL;<\/strong>.<\/li>\n<li><strong>Ottimizzare le tabelle dopo la pulizia<\/strong> &#8211; Dopo tutte le eliminazioni, ottimizza ogni tabella per recuperare lo spazio: <strong>OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_comments, wp_commentmeta, wp_term_relationships, wp_termmeta, wp_terms;<\/strong>. Questa operazione pu\u00f2 richiedere diversi minuti su database grandi. Non interromperla. Al termine, verifica le dimensioni del database con: <strong>SELECT table_name, ROUND(((data_length + index_length) \/ 1024 \/ 1024), 2) AS &#8216;Size (MB)&#8217; FROM information_schema.tables WHERE table_schema = &#8216;nome_database&#8217; ORDER BY (data_length + index_length) DESC;<\/strong>.<\/li>\n<\/ol>\n<h2>Limitare le Revisioni e gli Auto-Save in wp-config.php<\/h2>\n<p>Pulire il database \u00e8 importante, ma prevenire l&#8217;accumulo di dati inutili \u00e8 ancora meglio. WordPress offre alcune costanti che puoi definire nel file <strong>wp-config.php<\/strong> per limitare le revisioni e la frequenza degli auto-save. Queste impostazioni sono la prima cosa che configuro su ogni nuova installazione WordPress. Ecco le modifiche che consiglio e come implementarle correttamente:<\/p>\n<ol>\n<li><strong>Limitare il numero di revisioni<\/strong> &#8211; Aggiungi questa riga nel file wp-config.php, prima della riga &#8220;\/* That&#8217;s all, stop editing! *\/&#8221;: <strong>define(&#8216;WP_POST_REVISIONS&#8217;, 5);<\/strong>. Questo limita le revisioni a 5 per ogni articolo. Personalmente uso il valore 5 perch\u00e9 mi permette di tornare indietro se necessario, senza accumulare decine di versioni inutili. Se vuoi disabilitare completamente le revisioni, usa il valore <strong>false<\/strong>: define(&#8216;WP_POST_REVISIONS&#8217;, false); ma lo sconsiglio perch\u00e9 perdi la possibilit\u00e0 di recuperare versioni precedenti.<\/li>\n<li><strong>Aumentare l&#8217;intervallo di auto-save<\/strong> &#8211; Di default WordPress salva una bozza automatica ogni 60 secondi. Puoi aumentare questo intervallo con: <strong>define(&#8216;AUTOSAVE_INTERVAL&#8217;, 300);<\/strong>. Il valore \u00e8 in secondi, quindi 300 significa un auto-save ogni 5 minuti. Questo riduce significativamente il numero di auto-draft creati durante la scrittura. Non consiglio intervalli superiori a 5 minuti perch\u00e9 rischi di perdere troppo lavoro in caso di crash del browser.<\/li>\n<li><strong>Svuotare il cestino automaticamente<\/strong> &#8211; WordPress pu\u00f2 svuotare automaticamente il cestino dopo un certo numero di giorni. Aggiungi: <strong>define(&#8216;EMPTY_TRASH_DAYS&#8217;, 7);<\/strong>. Questo elimina definitivamente gli articoli e i commenti nel cestino dopo 7 giorni. Il valore di default \u00e8 30 giorni, che per la maggior parte dei siti \u00e8 troppo. Sette giorni sono sufficienti per accorgersi di un&#8217;eliminazione accidentale. Se vuoi disabilitare il cestino completamente, usa il valore 0, ma te lo sconsiglio fortemente.<\/li>\n<li><strong>Disabilitare la compressione delle revisioni<\/strong> &#8211; In wp-config.php puoi anche configurare la costante <strong>WP_MEMORY_LIMIT<\/strong> per assicurarti che le operazioni di pulizia del database abbiano abbastanza memoria: <strong>define(&#8216;WP_MEMORY_LIMIT&#8217;, &#8216;256M&#8217;);<\/strong>. Questo non \u00e8 direttamente legato alle revisioni, ma \u00e8 importante quando esegui operazioni massive sul database tramite plugin come WP-Optimize.<\/li>\n<li><strong>Verificare le impostazioni<\/strong> &#8211; Dopo aver aggiunto le costanti, verifica che funzionino. Crea un nuovo articolo, salvalo 10 volte e controlla quante revisioni vengono create. Dovrebbero essere al massimo 5 (o il numero che hai impostato). Puoi verificare anche dall&#8217;editor: nella sidebar a destra dell&#8217;editor Gutenberg, la sezione &#8220;Revisioni&#8221; mostrer\u00e0 al massimo il numero configurato. Se le revisioni non vengono limitate, controlla che la costante sia definita prima della riga require_once nel wp-config.php.<\/li>\n<\/ol>\n<h2>Schedulare la Pulizia Automatica e Monitorare i Risultati<\/h2>\n<p>Una pulizia fatta una volta sola serve a poco se non viene ripetuta regolarmente. Il database torna a gonfiarsi nel giro di poche settimane, specialmente su siti con pubblicazioni frequenti e molto traffico. La soluzione \u00e8 <strong>automatizzare la pulizia<\/strong> e monitorare costantemente le dimensioni e le prestazioni del database. Ecco come organizzo la manutenzione automatica sui siti che gestisco:<\/p>\n<ol>\n<li><strong>Schedulare la pulizia con WP-Optimize<\/strong> &#8211; WP-Optimize offre una funzione di <strong>pulizia programmata<\/strong> nella scheda Settings. Puoi impostare una pulizia automatica settimanale o bisettimanale che elimina revisioni, auto-draft, transient scaduti e commenti spam. Io imposto una pulizia settimanale ogni domenica alle 3:00 di notte, quando il traffico \u00e8 minimo. Assicurati di selezionare anche l&#8217;opzione per ottimizzare le tabelle durante la pulizia programmata.<\/li>\n<li><strong>Creare un cron job personalizzato<\/strong> &#8211; Per un controllo maggiore, creo un cron job che esegue le query SQL di pulizia tramite WP-CLI. Il comando \u00e8: <strong>wp db query &#8220;DELETE FROM wp_posts WHERE post_type = &#8216;revision'&#8221; &#8211;path=\/var\/www\/html\/wordpress<\/strong>. Lo inserisco nel crontab del server con: <strong>0 3 * * 0 \/usr\/local\/bin\/wp db query &#8220;DELETE FROM wp_posts WHERE post_type = &#8216;revision'&#8221; &#8211;path=\/var\/www\/html\/wordpress<\/strong>. Questo esegue la pulizia delle revisioni ogni domenica alle 3:00.<\/li>\n<li><strong>Monitorare le dimensioni del database<\/strong> &#8211; Uso uno script bash che controlla settimanalmente le dimensioni del database e mi invia un&#8217;email se superano una soglia. Lo script esegue la query <strong>SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE table_schema = &#8216;nome_db&#8217;<\/strong> e confronta il risultato con il valore atteso. Se il database supera una certa dimensione, significa che qualcosa sta accumulando dati pi\u00f9 del previsto e devo investigare.<\/li>\n<li><strong>Confrontare i tempi di query prima e dopo<\/strong> &#8211; Per misurare l&#8217;impatto della pulizia, uso il plugin <strong>Query Monitor<\/strong> che mostra il numero e il tempo di esecuzione di tutte le query SQL su ogni pagina. Prima della pulizia, annoto il numero totale di query e il tempo totale. Dopo la pulizia, confronto i valori. Nella mia esperienza, una buona pulizia riduce il tempo totale delle query del <strong>30-60%<\/strong> e il numero di query lente (quelle oltre i 50ms) del 70-80%. Su un sito che gestisco, il tempo medio di risposta \u00e8 passato da 2.3 secondi a 0.8 secondi dopo la prima pulizia completa.<\/li>\n<li><strong>Analizzare le query lente con il slow query log<\/strong> &#8211; Abilito il <strong>slow query log<\/strong> di MySQL per identificare le query che richiedono pi\u00f9 tempo. Nel file my.cnf aggiungo: <strong>slow_query_log = 1<\/strong>, <strong>slow_query_log_file = \/var\/log\/mysql\/slow.log<\/strong>, <strong>long_query_time = 1<\/strong>. Questo registra tutte le query che impiegano pi\u00f9 di 1 secondo. Analizzo il log con <strong>mysqldumpslow<\/strong> per trovare le query pi\u00f9 frequenti e pi\u00f9 lente. Spesso scopro che le query lente coinvolgono tabelle non ottimizzate o con indici mancanti, problemi che la pulizia e l&#8217;ottimizzazione risolvono.<\/li>\n<\/ol>\n<h2>FAQ &#8211; Domande Frequenti sulla Pulizia del Database WordPress<\/h2>\n<h3>Posso danneggiare il sito pulendo il database?<\/h3>\n<p>S\u00ec, se non fai attenzione puoi causare danni seri. Ecco perch\u00e9 il backup \u00e8 obbligatorio prima di qualsiasi operazione. Le query di pulizia che ho descritto sono sicure se eseguite correttamente, ma un errore di battitura in una query DELETE pu\u00f2 cancellare dati importanti. Se non ti senti sicuro con le query SQL, usa un plugin come WP-Optimize che offre le stesse funzionalit\u00e0 con un&#8217;interfaccia grafica e controlli di sicurezza integrati. In ogni caso, testa sempre su un ambiente di staging prima di operare sul sito in produzione.<\/p>\n<h3>Ogni quanto dovrei pulire il database?<\/h3>\n<p>Dipende dall&#8217;attivit\u00e0 del sito. Per un blog con 2-3 pubblicazioni a settimana, una pulizia mensile \u00e8 sufficiente. Per un e-commerce o un sito con molti utenti e commenti, consiglio una pulizia settimanale automatizzata. La regola che seguo io \u00e8: se il database cresce di pi\u00f9 del 10% al mese senza che ci sia un aumento proporzionale dei contenuti, \u00e8 ora di pulire. Monitorando le dimensioni del database nel tempo, troverai il ritmo giusto per il tuo sito specifico.<\/p>\n<h3>WP-Optimize \u00e8 sicuro da usare?<\/h3>\n<p><strong>WP-Optimize<\/strong> \u00e8 uno dei plugin pi\u00f9 affidabili per la pulizia del database WordPress. Ha oltre un milione di installazioni attive e viene aggiornato regolarmente. Lo uso personalmente su tutti i siti che gestisco senza aver mai avuto problemi. Tuttavia, come per qualsiasi operazione sul database, consiglio sempre di fare un backup prima di eseguire la pulizia, anche con il plugin. WP-Optimize stesso ti ricorda di farlo prima della prima pulizia.<\/p>\n<h3>Le revisioni sono davvero utili? Posso eliminarle tutte?<\/h3>\n<p>Le revisioni sono utili come sistema di versionamento dei contenuti. Se modifichi un articolo e il risultato non ti piace, puoi tornare a una versione precedente. Tuttavia, avere 50 revisioni per articolo \u00e8 eccessivo. Il mio consiglio \u00e8 di eliminare le revisioni vecchie e limitare quelle future a 3-5 per articolo tramite la costante <strong>WP_POST_REVISIONS<\/strong> in wp-config.php. Cos\u00ec mantieni la funzionalit\u00e0 senza sprecare spazio.<\/p>\n<h3>La pulizia del database influisce sulla SEO?<\/h3>\n<p>La pulizia del database non ha effetti diretti sulla SEO, perch\u00e9 elimina solo dati interni che non sono visibili ai motori di ricerca (revisioni, transient, metadati orfani). Tuttavia, ha un <strong>effetto indiretto molto positivo<\/strong>: un sito pi\u00f9 veloce viene premiato da Google nel ranking. La velocit\u00e0 di caricamento \u00e8 un fattore di ranking confermato, e un database pulito e ottimizzato contribuisce significativamente a ridurre i tempi di risposta del server (TTFB). Quindi s\u00ec, pulire il database aiuta la SEO, anche se indirettamente.<\/p>\n<h3>Cosa succede ai dati di WooCommerce durante la pulizia?<\/h3>\n<p>Se usi WooCommerce, fai molta attenzione durante la pulizia. Le tabelle di WooCommerce contengono dati degli ordini, dei prodotti e dei clienti che non devono essere eliminati. WP-Optimize riconosce le tabelle di WooCommerce e le tratta con cautela. Se usi query SQL manuali, assicurati di non toccare le tabelle che iniziano con <strong>wp_wc_<\/strong> o <strong>wp_woocommerce_<\/strong>. La pulizia delle revisioni e dei transient \u00e8 sicura anche con WooCommerce, ma evita di eliminare metadati dalla tabella wp_postmeta senza verificare che non appartengano a ordini o prodotti.<\/p>\n<h2>La Mia Soluzione Definitiva<\/h2>\n<p>La pulizia del database WordPress \u00e8 una delle attivit\u00e0 di manutenzione pi\u00f9 sottovalutate, eppure ha un impatto enorme sulle prestazioni del sito. Nel corso degli anni ho sviluppato una procedura che combina prevenzione e manutenzione: configuro le costanti in wp-config.php subito dopo l&#8217;installazione per limitare revisioni e auto-save, installo WP-Optimize con pulizia automatica settimanale, e una volta al mese eseguo una pulizia manuale approfondita con query SQL per eliminare metadati orfani e tabelle abbandonate. Monitoro tutto con Query Monitor e il slow query log di MySQL. I risultati parlano da soli: database pi\u00f9 leggeri del 60-80%, tempi di query dimezzati e siti che rispondono in meno di un secondo. Se il tuo sito WordPress \u00e8 diventato lento e non sai da dove cominciare, la pulizia del database \u00e8 quasi sempre la prima cosa da fare. Se hai bisogno di una mano per ottimizzare il tuo database WordPress o vuoi una consulenza personalizzata sulla manutenzione del tuo sito, <a href=\"https:\/\/darioiannascoli.it\/#contatti\">contattami direttamente dalla mia pagina contatti<\/a>: sar\u00f2 felice di aiutarti a rimettere in forma il tuo sito.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Scopri come pulire il database WordPress da revisioni, transient e meta orfani per velocizzare il sito. Procedura sicura con backup e strumenti consigliati.<\/p>\n","protected":false},"author":1,"featured_media":822,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Come Pulire il Database WordPress per Velocizzare il Sito","_seopress_titles_desc":"Scopri come pulire il database WordPress da revisioni, transient e meta orfani per velocizzare il sito. Procedura sicura con backup e plugin consigliati.","_seopress_robots_index":"","footnotes":""},"categories":[2],"tags":[49,13,10,17],"class_list":["post-743","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-database-mysql","tag-ottimizzazione-wordpress","tag-plugin-wordpress","tag-wordpress-lento"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/743","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=743"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/743\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/822"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=743"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=743"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=743"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}