{"id":19299,"date":"2026-08-16T18:46:15","date_gmt":"2026-08-16T16:46:15","guid":{"rendered":"https:\/\/xlogic.org\/blog\/?p=19299"},"modified":"2026-08-16T18:53:35","modified_gmt":"2026-08-16T16:53:35","slug":"ottimizzare-il-database-wordpress","status":"publish","type":"post","link":"https:\/\/xlogic.org\/blog\/ottimizzare-il-database-wordpress.html\/","title":{"rendered":"Come Ottimizzare il Database WordPress nel 2026: Guida Essenziale"},"content":{"rendered":"<p><strong>Ottimizzare il database WordPress<\/strong> nel 2026 significa individuare ci\u00f2 che rallenta realmente il sito prima di cancellare dati, modificare tabelle o installare l&#8217;ennesimo plugin di pulizia.<\/p>\n<p>Un sito WordPress pu\u00f2 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.<\/p>\n<p>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.<\/p>\n<p>Per questo motivo <strong>ottimizzare il database WordPress<\/strong> non significa semplicemente premere periodicamente un pulsante \u201cPulisci\u201d.<\/p>\n<p>Il metodo corretto \u00e8:<\/p>\n<p><strong>Misura \u2192 Analizza \u2192 Backup \u2192 Correggi \u2192 Ottimizza \u2192 Verifica<\/strong><\/p>\n<p>In questa guida vedremo come controllare <code>wp_options<\/code>, autoload, transient, revisioni, tabelle grandi e query lente, come utilizzare WP-CLI e quando Redis o una object cache persistente possono realmente aiutare.<\/p>\n<h2>In breve: perch\u00e9 il database WordPress pu\u00f2 rallentare il sito?<\/h2>\n<p>WordPress utilizza il database per recuperare molte delle informazioni necessarie a generare una pagina.<\/p>\n<p>Quando il database o il codice che lo interroga diventano inefficienti, il server pu\u00f2 dover eseguire pi\u00f9 lavoro del necessario.<\/p>\n<p>Tra le cause pi\u00f9 comuni troviamo:<\/p>\n<ul>\n<li>opzioni autoload troppo pesanti;<\/li>\n<li>plugin che eseguono troppe query;<\/li>\n<li>query lente o ripetute;<\/li>\n<li>tabelle molto grandi;<\/li>\n<li>transient scaduti o mal gestiti;<\/li>\n<li>revisioni accumulate;<\/li>\n<li>dati lasciati da plugin non pi\u00f9 utilizzati;<\/li>\n<li>tabelle prive degli indici necessari;<\/li>\n<li>WooCommerce con grandi quantit\u00e0 di dati;<\/li>\n<li>cron o attivit\u00e0 pianificate che generano continuamente nuove righe;<\/li>\n<li>assenza di object cache persistente dove sarebbe utile.<\/li>\n<\/ul>\n<p>La cosa importante \u00e8 capire che <strong>non tutti questi problemi si risolvono allo stesso modo<\/strong>. Per questo motivo il primo passaggio deve essere sempre l&#8217;analisi.<\/p>\n<h2>Cos&#8217;\u00e8 il database WordPress?<\/h2>\n<p>Una normale installazione WordPress utilizza diverse tabelle.<\/p>\n<p>Tra quelle principali troviamo:<\/p>\n<ul>\n<li><code>wp_posts<\/code>;<\/li>\n<li><code>wp_postmeta<\/code>;<\/li>\n<li><code>wp_options<\/code>;<\/li>\n<li><code>wp_users<\/code>;<\/li>\n<li><code>wp_usermeta<\/code>;<\/li>\n<li><code>wp_terms<\/code>;<\/li>\n<li><code>wp_termmeta<\/code>;<\/li>\n<li><code>wp_term_taxonomy<\/code>;<\/li>\n<li><code>wp_term_relationships<\/code>;<\/li>\n<li><code>wp_comments<\/code>;<\/li>\n<li><code>wp_commentmeta<\/code>.<\/li>\n<\/ul>\n<p>Il prefisso <code>wp_<\/code> \u00e8 quello predefinito e pu\u00f2 essere differente sul sito reale.<\/p>\n<p>Plugin e temi possono inoltre creare tabelle personalizzate, righe aggiuntive in <code>wp_options<\/code>, metadati, transient, eventi cron e configurazioni proprie.<\/p>\n<p>Di conseguenza, due siti WordPress apparentemente simili possono avere database molto diversi.<\/p>\n<h2>Prima di ottimizzare il database WordPress: crea un backup<\/h2>\n<p><strong>Prima di ottimizzare il database WordPress<\/strong> \u00e8 necessario disporre di un backup recente e recuperabile.<\/p>\n<p>Questo \u00e8 particolarmente importante per:<\/p>\n<ul>\n<li>WooCommerce;<\/li>\n<li>membership;<\/li>\n<li>LMS;<\/li>\n<li>siti con utenti registrati;<\/li>\n<li>sistemi di prenotazione;<\/li>\n<li>marketplace;<\/li>\n<li>portali aziendali.<\/li>\n<\/ul>\n<p>Un errore sul database pu\u00f2 avere effetto immediato sull&#8217;intero sito.<\/p>\n<p>La regola deve quindi essere:<\/p>\n<p><strong>backup prima, ottimizzazione dopo.<\/strong><\/p>\n<p>Per interventi complessi \u00e8 preferibile utilizzare anche uno staging. Puoi approfondire il flusso operativo nella guida Xlogic dedicata allo <a href=\"https:\/\/xlogic.org\/blog\/staging-wordpress.html\/\">staging WordPress con Softaculous<\/a>.<\/p>\n<h2>Database grande e database lento non sono la stessa cosa<\/h2>\n<p>Un database di grandi dimensioni non \u00e8 necessariamente lento.<\/p>\n<p>Allo stesso modo, un database relativamente piccolo pu\u00f2 generare problemi se una query viene eseguita centinaia di volte o utilizza una struttura inefficiente.<\/p>\n<p>Le prestazioni dipendono da numerosi elementi:<\/p>\n<ul>\n<li>struttura delle tabelle;<\/li>\n<li>numero di righe;<\/li>\n<li>tipo di query;<\/li>\n<li>indici;<\/li>\n<li>frequenza delle richieste;<\/li>\n<li>dati caricati automaticamente;<\/li>\n<li>plugin;<\/li>\n<li>cache;<\/li>\n<li>risorse disponibili.<\/li>\n<\/ul>\n<p>Per questo motivo osservare soltanto quanti megabyte occupa il database pu\u00f2 portare a una diagnosi sbagliata.<\/p>\n<h2><code>wp_options<\/code> e autoload: uno dei controlli pi\u00f9 importanti<\/h2>\n<p>La tabella <code>wp_options<\/code> contiene numerose impostazioni utilizzate da WordPress, plugin e temi.<\/p>\n<p>Una delle aree pi\u00f9 importanti da controllare riguarda le <strong>opzioni autoload<\/strong>.<\/p>\n<p>Le opzioni autoload sono configurazioni che WordPress carica automaticamente durante l&#8217;esecuzione. Questo comportamento \u00e8 utile per informazioni utilizzate frequentemente, ma pu\u00f2 diventare inefficiente se vengono caricati automaticamente grandi volumi di dati non necessari.<\/p>\n<p>WordPress considera le opzioni autoload un elemento rilevante per le prestazioni. La <a href=\"https:\/\/developer.wordpress.org\/advanced-administration\/performance\/optimization\/\" target=\"_blank\" rel=\"noopener\">documentazione ufficiale WordPress sull&#8217;ottimizzazione delle prestazioni<\/a> raccomanda di mantenere sotto controllo la quantit\u00e0 complessiva dei dati caricati automaticamente.<\/p>\n<p>Per <strong>ottimizzare il database WordPress<\/strong> in modo efficace \u00e8 quindi importante individuare le opzioni autoload pi\u00f9 pesanti e capire a quale componente appartengono.<\/p>\n<h2>Cosa pu\u00f2 finire in autoload?<\/h2>\n<p>Tra i dati che possono comparire in <code>wp_options<\/code> troviamo:<\/p>\n<ul>\n<li>impostazioni dei plugin;<\/li>\n<li>configurazioni del tema;<\/li>\n<li>dati temporanei;<\/li>\n<li>cache applicative;<\/li>\n<li>informazioni di plugin disinstallati;<\/li>\n<li>opzioni molto grandi salvate da componenti non ottimizzati.<\/li>\n<\/ul>\n<p>Il problema non \u00e8 semplicemente il numero delle righe.<\/p>\n<p>Una singola opzione molto grande pu\u00f2 pesare pi\u00f9 di centinaia di piccole configurazioni.<\/p>\n<h2>Come controllare la dimensione delle opzioni autoload<\/h2>\n<p>Il primo controllo pu\u00f2 essere effettuato da:<\/p>\n<p><strong>WordPress \u2192 Strumenti \u2192 Salute del sito<\/strong><\/p>\n<p>WordPress include un test specifico dedicato alle opzioni autoload.<\/p>\n<p>Per un&#8217;analisi pi\u00f9 approfondita possiamo utilizzare SQL. Prima di eseguire query manuali identifica sempre il prefisso corretto delle tabelle.<\/p>\n<p>Un esempio diagnostico \u00e8:<\/p>\n<pre><code>SELECT SUM(LENGTH(option_value)) AS autoload_size\r\nFROM wp_options\r\nWHERE autoload IN ('yes','on','auto-on','auto');<\/code><\/pre>\n<p>Questa query serve a <strong>misurare<\/strong>, non modifica i dati.<\/p>\n<h2>Individuare le opzioni autoload pi\u00f9 grandi<\/h2>\n<p>Per trovare le opzioni pi\u00f9 pesanti possiamo utilizzare:<\/p>\n<pre><code>SELECT\r\n    option_name,\r\n    LENGTH(option_value) AS size_bytes\r\nFROM wp_options\r\nWHERE autoload IN ('yes','on','auto-on','auto')\r\nORDER BY size_bytes DESC\r\nLIMIT 30;<\/code><\/pre>\n<p>Il risultato va interpretato con attenzione.<\/p>\n<p>Non bisogna eliminare automaticamente le prime righe della lista.<\/p>\n<p>Per ogni opzione dobbiamo capire:<\/p>\n<ul>\n<li>quale plugin o tema la utilizza;<\/li>\n<li>se il componente \u00e8 ancora presente;<\/li>\n<li>se l&#8217;opzione \u00e8 necessaria;<\/li>\n<li>se il dato pu\u00f2 essere rigenerato;<\/li>\n<li>quanto spesso viene utilizzato.<\/li>\n<\/ul>\n<p><strong>Grande non significa automaticamente inutile.<\/strong><\/p>\n<h2>Non modificare tutti gli autoload in <code>no<\/code><\/h2>\n<p>Una delle correzioni peggiori sarebbe eseguire una modifica indiscriminata come:<\/p>\n<pre><code>UPDATE wp_options SET autoload='no';<\/code><\/pre>\n<p><strong>Non va fatto.<\/strong><\/p>\n<p>Alcune opzioni vengono caricate automaticamente proprio perch\u00e9 sono necessarie frequentemente.<\/p>\n<p>Disabilitare in massa l&#8217;autoload pu\u00f2 aumentare altre query, compromettere plugin, provocare comportamenti inattesi o peggiorare invece di migliorare le prestazioni.<\/p>\n<p>Per <strong>ottimizzare il database WordPress<\/strong> bisogna intervenire selettivamente sui dati realmente identificati come problematici.<\/p>\n<h2>Transient WordPress: cosa sono?<\/h2>\n<p>I transient sono dati temporanei memorizzati attraverso la Transients API di WordPress.<\/p>\n<p>Vengono utilizzati, ad esempio, per conservare temporaneamente:<\/p>\n<ul>\n<li>risultati di query;<\/li>\n<li>risposte di API;<\/li>\n<li>dati elaborati;<\/li>\n<li>informazioni che possono essere rigenerate;<\/li>\n<li>cache applicative.<\/li>\n<\/ul>\n<p>Un transient dovrebbe quindi essere considerato un dato temporaneo, non un archivio permanente.<\/p>\n<p>Per approfondire il comportamento tecnico puoi consultare la <a href=\"https:\/\/developer.wordpress.org\/apis\/transients\/\" target=\"_blank\" rel=\"noopener\">documentazione ufficiale WordPress sulla Transients API<\/a>.<\/p>\n<h2>Eliminare i transient scaduti<\/h2>\n<p>Se utilizzi WP-CLI possiamo visualizzare i transient con:<\/p>\n<pre><code>wp transient list<\/code><\/pre>\n<p>Per eliminare soltanto quelli scaduti:<\/p>\n<pre><code>wp transient delete --expired<\/code><\/pre>\n<p>Esiste anche:<\/p>\n<pre><code>wp transient delete --all<\/code><\/pre>\n<p>ma eliminare tutti i transient indiscriminatamente non deve diventare una routine. Molti verranno semplicemente rigenerati dal sito e dai plugin.<\/p>\n<h2>Object cache e transient<\/h2>\n<p>Quando viene utilizzata una object cache persistente, il comportamento di alcuni dati temporanei pu\u00f2 differire rispetto a un sito che utilizza soltanto il database.<\/p>\n<p>WP-CLI permette anche di verificare il tipo di implementazione dei transient:<\/p>\n<pre><code>wp transient type<\/code><\/pre>\n<p>Questo aiuta a capire se i transient vengono gestiti attraverso il database o tramite una object cache.<\/p>\n<h2>Revisioni WordPress<\/h2>\n<p>WordPress conserva le revisioni per permettere di recuperare versioni precedenti di articoli e pagine.<\/p>\n<p>\u00c8 una funzione utile.<\/p>\n<p>Su siti molto attivi, per\u00f2, le revisioni possono crescere significativamente, soprattutto con numerosi articoli, page builder, molti autori o pagine modificate frequentemente.<\/p>\n<p>Non significa che vadano eliminate tutte.<\/p>\n<p>Una strategia pi\u00f9 equilibrata consiste nel limitarne il numero futuro.<\/p>\n<p>Ad esempio, in <code>wp-config.php<\/code>:<\/p>\n<pre><code>define( 'WP_POST_REVISIONS', 10 );<\/code><\/pre>\n<p>In questo esempio WordPress conserver\u00e0 un numero massimo definito di revisioni.<\/p>\n<p>La quantit\u00e0 ideale dipende dal tipo di sito.<\/p>\n<h2>Plugin disinstallati e dati residui<\/h2>\n<p>Rimuovere un plugin non significa necessariamente eliminare tutti i dati che ha creato.<\/p>\n<p>Possono rimanere:<\/p>\n<ul>\n<li>tabelle;<\/li>\n<li>opzioni;<\/li>\n<li>metadati;<\/li>\n<li>transient;<\/li>\n<li>cron;<\/li>\n<li>log.<\/li>\n<\/ul>\n<p>Questo pu\u00f2 essere intenzionale: alcuni plugin mantengono i dati per permettere una futura reinstallazione.<\/p>\n<p>Prima di cancellare manualmente una tabella o un&#8217;opzione bisogna quindi identificare con certezza a quale componente appartenga.<\/p>\n<p><strong>Una tabella sconosciuta non \u00e8 automaticamente una tabella inutile.<\/strong><\/p>\n<h2>Come trovare le tabelle pi\u00f9 grandi<\/h2>\n<p>Per capire dove viene utilizzato lo spazio possiamo interrogare <code>information_schema<\/code>.<\/p>\n<p>Ad esempio:<\/p>\n<pre><code>SELECT\r\n    table_name,\r\n    ROUND((data_length + index_length) \/ 1024 \/ 1024, 2) AS size_mb\r\nFROM information_schema.tables\r\nWHERE table_schema = DATABASE()\r\nORDER BY (data_length + index_length) DESC;<\/code><\/pre>\n<p>Questa query mostra le tabelle ordinate per dimensione.<\/p>\n<p>Su un WooCommerce, ad esempio, la distribuzione dei dati pu\u00f2 essere molto diversa rispetto a un semplice blog.<\/p>\n<h2><code>wp_postmeta<\/code>: perch\u00e9 pu\u00f2 crescere molto<\/h2>\n<p><code>wp_postmeta<\/code> contiene metadati associati a post e altri tipi di contenuto.<\/p>\n<p>Pu\u00f2 crescere rapidamente nei siti che utilizzano:<\/p>\n<ul>\n<li>WooCommerce;<\/li>\n<li>page builder;<\/li>\n<li>custom fields;<\/li>\n<li>plugin SEO;<\/li>\n<li>sistemi complessi di metadati.<\/li>\n<\/ul>\n<p>Una tabella grande non va comunque ripulita cancellando righe casualmente.<\/p>\n<p>Un metadato pu\u00f2 essere associato a prodotti, pagine, ordini, template o configurazioni.<\/p>\n<p>La pulizia deve quindi essere consapevole.<\/p>\n<h2>WP-CLI per ottimizzare il database WordPress<\/h2>\n<p><strong>WP-CLI pu\u00f2 aiutare a ottimizzare il database WordPress<\/strong> e a verificarne lo stato direttamente dal terminale.<\/p>\n<p>Per controllare il database:<\/p>\n<pre><code>wp db check<\/code><\/pre>\n<p>Per creare un backup SQL:<\/p>\n<pre><code>wp db export backup-prima-ottimizzazione.sql<\/code><\/pre>\n<p>Conserva il dump in un percorso non pubblicamente scaricabile.<\/p>\n<p>Per ottimizzare le tabelle:<\/p>\n<pre><code>wp db optimize<\/code><\/pre>\n<p>Il comando \u00e8 documentato ufficialmente nella pagina <a href=\"https:\/\/developer.wordpress.org\/cli\/commands\/db\/optimize\/\" target=\"_blank\" rel=\"noopener\">WP-CLI: wp db optimize<\/a>.<\/p>\n<p>Per approfondire la gestione del CMS da terminale puoi leggere anche la guida Xlogic <a href=\"https:\/\/xlogic.org\/blog\/wp-cli-wordpress.html\/\">WP-CLI 2026: guida ai comandi WordPress<\/a>.<\/p>\n<h2>Cosa non risolve <code>wp db optimize<\/code><\/h2>\n<p>Il comando non risolve automaticamente:<\/p>\n<ul>\n<li>query inefficienti;<\/li>\n<li>autoload eccessivo;<\/li>\n<li>plugin mal progettati;<\/li>\n<li>troppe chiamate al database;<\/li>\n<li>tabelle inutili;<\/li>\n<li>mancanza di indici appropriati;<\/li>\n<li>processi cron problematici.<\/li>\n<\/ul>\n<p>L&#8217;ottimizzazione fisica delle tabelle \u00e8 soltanto uno dei possibili interventi.<\/p>\n<h2><code>OPTIMIZE TABLE<\/code> non \u00e8 una cura universale<\/h2>\n<p>Un errore comune \u00e8 considerare l&#8217;ottimizzazione del database come sinonimo di:<\/p>\n<pre><code>OPTIMIZE TABLE ...<\/code><\/pre>\n<p>Se un plugin esegue una query inefficiente centinaia di volte, ottimizzare fisicamente la tabella potrebbe avere un impatto minimo.<\/p>\n<p>Bisogna prima capire:<\/p>\n<p><strong>quale query \u00e8 lenta e quale componente la sta generando?<\/strong><\/p>\n<h2>Come individuare query lente<\/h2>\n<p>Per un&#8217;analisi approfondita possiamo utilizzare strumenti come:<\/p>\n<ul>\n<li>Query Monitor;<\/li>\n<li>slow query log di MySQL\/MariaDB, quando disponibile;<\/li>\n<li>strumenti APM;<\/li>\n<li>profiling;<\/li>\n<li>log server;<\/li>\n<li>strumenti del pannello hosting.<\/li>\n<\/ul>\n<p>Gli elementi da osservare sono:<\/p>\n<ul>\n<li>durata delle query;<\/li>\n<li>numero di chiamate;<\/li>\n<li>query ripetute;<\/li>\n<li>componente che le genera;<\/li>\n<li>pagina o operazione interessata.<\/li>\n<\/ul>\n<p>Una singola query lenta e cento query relativamente piccole possono produrre problemi differenti.<\/p>\n<h2>WooCommerce e database WordPress<\/h2>\n<p>WooCommerce rende il database molto pi\u00f9 dinamico.<\/p>\n<p>Durante il normale utilizzo possono essere continuamente registrati:<\/p>\n<ul>\n<li>prodotti;<\/li>\n<li>variazioni;<\/li>\n<li>ordini;<\/li>\n<li>clienti;<\/li>\n<li>pagamenti;<\/li>\n<li>stock;<\/li>\n<li>sessioni;<\/li>\n<li>coupon;<\/li>\n<li>attivit\u00e0 pianificate;<\/li>\n<li>log.<\/li>\n<\/ul>\n<p>Per questo motivo, su WooCommerce, <strong>ottimizzare il database WordPress<\/strong> richiede maggiore attenzione.<\/p>\n<p>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.<\/p>\n<p>Per siti di vendita online puoi approfondire anche le soluzioni <a href=\"https:\/\/xlogic.org\/hosting-ecommerce\/\">Hosting eCommerce Xlogic<\/a>.<\/p>\n<h2>Action Scheduler<\/h2>\n<p>WooCommerce e molti plugin utilizzano Action Scheduler per attivit\u00e0 in background.<\/p>\n<p>Un numero molto elevato di azioni pendenti o fallite pu\u00f2 essere il sintomo di:<\/p>\n<ul>\n<li>processi che non terminano;<\/li>\n<li>cron problematici;<\/li>\n<li>plugin che generano continuamente nuove attivit\u00e0;<\/li>\n<li>risorse insufficienti;<\/li>\n<li>errori applicativi.<\/li>\n<\/ul>\n<p>La soluzione non deve essere automaticamente \u201csvuotare tutto\u201d.<\/p>\n<p>Bisogna identificare <strong>perch\u00e9 le azioni si accumulano<\/strong>.<\/p>\n<h2>WP-Cron e crescita del database<\/h2>\n<p>WP-Cron pu\u00f2 essere coinvolto nella crescita continua di alcune tabelle.<\/p>\n<p>Con WP-CLI possiamo visualizzare gli eventi programmati:<\/p>\n<pre><code>wp cron event list<\/code><\/pre>\n<p>Se un plugin crea ripetutamente attivit\u00e0 o genera errori durante la loro esecuzione, eliminare soltanto i dati accumulati non risolve la causa.<\/p>\n<p>Bisogna correggere il processo che continua a generarli.<\/p>\n<h2>Redis e object cache persistente<\/h2>\n<p>Una <strong>object cache persistente<\/strong> consente di conservare in memoria dati che altrimenti dovrebbero essere recuperati ripetutamente dal database.<\/p>\n<p>Questo pu\u00f2 ridurre il numero di query necessarie durante alcune richieste.<\/p>\n<p>Tra i sistemi comunemente utilizzati troviamo Redis.<\/p>\n<h2>Redis non sostituisce l&#8217;ottimizzazione del database<\/h2>\n<p>Redis pu\u00f2 aiutare, ma non sostituisce il lavoro necessario per <strong>ottimizzare il database WordPress<\/strong>.<\/p>\n<p>Redis non corregge:<\/p>\n<ul>\n<li>query SQL mal progettate;<\/li>\n<li>plugin inefficienti;<\/li>\n<li>autoload eccessivo;<\/li>\n<li>tabelle obsolete;<\/li>\n<li>processi cron errati;<\/li>\n<li>grandi quantit\u00e0 di dati inutili.<\/li>\n<\/ul>\n<p>Il principio corretto \u00e8:<\/p>\n<p><strong>correggi la causa \u2192 utilizza la cache dove appropriato<\/strong><\/p>\n<p>e non:<\/p>\n<p><strong>attiva Redis \u2192 ignora il database.<\/strong><\/p>\n<h2>Object cache e page cache non sono la stessa cosa<\/h2>\n<p>\u00c8 importante distinguere i livelli di caching.<\/p>\n<p>La <strong>page cache<\/strong> pu\u00f2 memorizzare una pagina gi\u00e0 generata evitando di ricostruirla completamente a ogni visita.<\/p>\n<p>La <strong>object cache<\/strong> conserva invece oggetti e dati recuperati durante l&#8217;esecuzione di WordPress.<\/p>\n<p>Un sito pu\u00f2 beneficiare di entrambe.<\/p>\n<p>Se utilizzi LiteSpeed Cache, quindi, non significa automaticamente che una object cache persistente sia attiva.<\/p>\n<h2>Come ottimizzare il database WordPress nel 2026<\/h2>\n<p>La checklist seguente permette di <strong>ottimizzare il database WordPress<\/strong> con un metodo pi\u00f9 sicuro.<\/p>\n<h3>1. Crea un backup<\/h3>\n<p>Prima di modificare qualsiasi dato:<\/p>\n<pre><code>wp db export backup-prima-ottimizzazione.sql<\/code><\/pre>\n<p>oppure utilizza il sistema di backup disponibile sull&#8217;hosting.<\/p>\n<h3>2. Misura<\/h3>\n<p>Controlla:<\/p>\n<ul>\n<li>dimensione complessiva;<\/li>\n<li>tabelle pi\u00f9 grandi;<\/li>\n<li>autoload;<\/li>\n<li>transient;<\/li>\n<li>revisioni;<\/li>\n<li>query;<\/li>\n<li>cron;<\/li>\n<li>attivit\u00e0 pianificate.<\/li>\n<\/ul>\n<h3>3. Analizza<\/h3>\n<p>Individua le anomalie. Non cancellare ancora nulla.<\/p>\n<h3>4. Trova la causa<\/h3>\n<p>Chiediti:<\/p>\n<p><strong>quale plugin, tema o processo sta creando questi dati?<\/strong><\/p>\n<h3>5. Correggi selettivamente<\/h3>\n<p>Intervieni soltanto sui dati identificati.<\/p>\n<h3>6. Ottimizza<\/h3>\n<p>Quando necessario:<\/p>\n<pre><code>wp db optimize<\/code><\/pre>\n<h3>7. Verifica<\/h3>\n<p>Dopo l&#8217;intervento controlla:<\/p>\n<ul>\n<li>frontend;<\/li>\n<li><code>\/wp-admin\/<\/code>;<\/li>\n<li>errori;<\/li>\n<li>WooCommerce;<\/li>\n<li>query;<\/li>\n<li>cron;<\/li>\n<li>dimensioni delle tabelle;<\/li>\n<li>performance.<\/li>\n<\/ul>\n<p>Questo processo \u00e8 molto pi\u00f9 sicuro di una pulizia automatica indiscriminata.<\/p>\n<h2>Cosa NON fare per ottimizzare il database WordPress<\/h2>\n<h3>Non eliminare tutte le opzioni autoload<\/h3>\n<p>Molte sono necessarie.<\/p>\n<h3>Non impostare tutti gli autoload su <code>no<\/code><\/h3>\n<p>Potresti aumentare le query o compromettere il funzionamento del sito.<\/p>\n<h3>Non cancellare tabelle che non riconosci<\/h3>\n<p>Prima identifica con certezza il componente che le utilizza.<\/p>\n<h3>Non eliminare tutti i transient continuamente<\/h3>\n<p>Molti vengono rigenerati e l&#8217;operazione potrebbe non risolvere alcun problema reale.<\/p>\n<h3>Non cancellare indiscriminatamente <code>postmeta<\/code><\/h3>\n<p>I dati potrebbero essere necessari a prodotti, pagine, ordini e plugin.<\/p>\n<h3>Non importare un database vecchio sopra WooCommerce live<\/h3>\n<p>Potresti perdere ordini e clienti recenti.<\/p>\n<h3>Non considerare <code>wp db optimize<\/code> una soluzione universale<\/h3>\n<p>Ottimizza le tabelle, ma non corregge automaticamente query applicative inefficienti.<\/p>\n<h3>Non intervenire senza backup<\/h3>\n<p>Una singola query SQL errata pu\u00f2 modificare migliaia di record.<\/p>\n<h2>Quanto spesso bisogna ottimizzare il database?<\/h2>\n<p>Non esiste una frequenza valida per tutti.<\/p>\n<p>Un blog con pochi aggiornamenti ha esigenze diverse da un WooCommerce, un portale, una community, un LMS o un sito con molte operazioni giornaliere.<\/p>\n<p>\u00c8 preferibile basare la manutenzione su segnali reali:<\/p>\n<ul>\n<li>crescita anomala;<\/li>\n<li>peggioramento delle prestazioni;<\/li>\n<li>Site Health;<\/li>\n<li>query lente;<\/li>\n<li>errori;<\/li>\n<li>plugin rimossi;<\/li>\n<li>migrazioni;<\/li>\n<li>forte aumento del traffico.<\/li>\n<\/ul>\n<p>Non serve effettuare pulizie invasive ogni settimana senza motivo.<\/p>\n<h2>Database WordPress su hosting Xlogic<\/h2>\n<p>Un database efficiente \u00e8 soltanto una parte dello stack WordPress.<\/p>\n<p>Le prestazioni complessive dipendono dall&#8217;interazione tra:<\/p>\n<p><strong>WordPress \u2192 plugin \u2192 PHP \u2192 database \u2192 cache \u2192 storage \u2192 server<\/strong><\/p>\n<p>Su un ambiente hosting moderno, tecnologie come storage SSD NVMe, PHP aggiornato, LiteSpeed e sistemi di caching possono ridurre significativamente i tempi di risposta.<\/p>\n<p>Ma un plugin che genera query inefficienti continuer\u00e0 comunque a richiedere risorse.<\/p>\n<p>Per questo motivo l&#8217;ottimizzazione deve partire dall&#8217;applicazione e dai dati reali. Per progetti WordPress puoi consultare anche le soluzioni <a href=\"https:\/\/xlogic.org\/hosting-wordpress\/\">Hosting WordPress Xlogic<\/a>.<\/p>\n<h2>Domande frequenti sull&#8217;ottimizzazione del database WordPress<\/h2>\n<h3>Come capire se devo ottimizzare il database WordPress?<\/h3>\n<p>Non basarti soltanto sulla dimensione. Controlla Site Health, opzioni autoload, tabelle pi\u00f9 grandi, query lente, transient, cron e crescita del database nel tempo.<\/p>\n<h3>Quanto devono pesare le opzioni autoload?<\/h3>\n<p>WordPress utilizza un controllo specifico in Site Health per segnalare quando il carico delle opzioni autoload pu\u00f2 diventare problematico. \u00c8 comunque una soglia diagnostica e non un valore magico valido per ogni sito.<\/p>\n<h3>Posso cancellare tutte le opzioni autoload?<\/h3>\n<p>No. Molte sono necessarie a WordPress, temi e plugin e devono essere analizzate singolarmente.<\/p>\n<h3>Come elimino i transient scaduti?<\/h3>\n<p>Con WP-CLI:<\/p>\n<pre><code>wp transient delete --expired<\/code><\/pre>\n<h3>Come verifico se i transient usano il database o una object cache?<\/h3>\n<p>Puoi utilizzare:<\/p>\n<pre><code>wp transient type<\/code><\/pre>\n<h3>Come controllo il database con WP-CLI?<\/h3>\n<p>Puoi iniziare con:<\/p>\n<pre><code>wp db check<\/code><\/pre>\n<h3>Come creo un backup SQL?<\/h3>\n<p>Con:<\/p>\n<pre><code>wp db export backup.sql<\/code><\/pre>\n<p>Evita di lasciare il dump in una directory pubblicamente accessibile.<\/p>\n<h3>Come ottimizzo le tabelle?<\/h3>\n<p>Puoi utilizzare:<\/p>\n<pre><code>wp db optimize<\/code><\/pre>\n<h3>Redis rende inutile ottimizzare il database WordPress?<\/h3>\n<p>No. Redis pu\u00f2 ridurre alcuni accessi ripetitivi al database, ma non corregge query inefficienti, autoload eccessivo o dati inutili.<\/p>\n<h3>Le revisioni devono essere eliminate?<\/h3>\n<p>Non necessariamente. Sono utili. Se diventano eccessive \u00e8 possibile limitarne il numero futuro tramite <code>WP_POST_REVISIONS<\/code>.<\/p>\n<h3>Un database molto grande \u00e8 necessariamente lento?<\/h3>\n<p>No. Le prestazioni dipendono anche da query, indici, cache, frequenza degli accessi e struttura dei dati.<\/p>\n<h3>Posso usare un plugin di pulizia?<\/h3>\n<p>S\u00ec, ma devi sapere quali dati verranno eliminati. Un&#8217;interfaccia grafica non rende automaticamente sicura un&#8217;operazione distruttiva.<\/p>\n<h2>Conclusioni<\/h2>\n<p><strong>Ottimizzare il database WordPress<\/strong> significa prima di tutto capire come vengono utilizzati i dati.<\/p>\n<p>Non esiste un pulsante universale capace di correggere automaticamente autoload, transient, revisioni, query lente, plugin inefficienti, WooCommerce, cron e tabelle cresciute nel tempo.<\/p>\n<p>Il workflow consigliato resta:<\/p>\n<p><strong>Misura \u2192 Analizza \u2192 Backup \u2192 Correggi \u2192 Ottimizza \u2192 Verifica<\/strong><\/p>\n<p>Le aree da controllare con maggiore attenzione sono:<\/p>\n<ul>\n<li><code>wp_options<\/code>;<\/li>\n<li>autoload;<\/li>\n<li>transient;<\/li>\n<li>revisioni;<\/li>\n<li>tabelle grandi;<\/li>\n<li><code>wp_postmeta<\/code>;<\/li>\n<li>query lente;<\/li>\n<li>cron;<\/li>\n<li>WooCommerce;<\/li>\n<li>object cache.<\/li>\n<\/ul>\n<p>WP-CLI pu\u00f2 semplificare numerose attivit\u00e0 di controllo e manutenzione, mentre Redis e altri sistemi di object caching possono ridurre alcuni accessi ripetitivi al database.<\/p>\n<p>Ma nessuno strumento sostituisce una diagnosi corretta.<\/p>\n<p>Un database efficiente non \u00e8 necessariamente quello pi\u00f9 piccolo: \u00e8 quello che contiene i dati necessari e permette a WordPress di recuperarli senza lavoro inutile.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ottimizzare il database WordPress nel 2026 significa individuare ci\u00f2 che rallenta realmente il sito prima di cancellare dati, modificare tabelle o installare l&#8217;ennesimo plugin di pulizia. Un sito WordPress pu\u00f2 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, [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":19306,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"no","_lmt_disable":"","footnotes":""},"categories":[5],"tags":[],"class_list":["post-19299","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"modified_by":"Team tecnico Xlogic","_links":{"self":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/posts\/19299","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/comments?post=19299"}],"version-history":[{"count":0,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/posts\/19299\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/media\/19306"}],"wp:attachment":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/media?parent=19299"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/categories?post=19299"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/tags?post=19299"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}