Come riparare un database WordPress lento: una checklist in 4 passaggi

La dashboard di amministrazione di WordPress non dovrebbe impiegare cinque secondi per caricarsi. Se lo fa, il problema potrebbe non essere il tuo piano di hosting o le tue immagini. Potrebbe essere il tuo database.

Il tuo database sta silenziosamente accumulando anni di spazzatura come transienti scaduti, migliaia di revisioni di post e dati autoloaded da plugin che hai eliminato anni fa.

La maggior parte di esso è invisibile in wp-admin e non influisce su ciò che vedono i visitatori. Ma si accumula e alla fine rallenta tutto.

Ho diagnosticato siti in cui un singolo plugin stava generando 80 query al database per caricamento di pagina. L'host andava bene. La cache era configurata correttamente. Nulla ha fatto la differenza finché il problema effettivo del database non è stato risolto.

In questo post, ti mostrerò come identificare il collo di bottiglia, ripulire il bloat del database, correggere le tabelle pesanti che sopravvivono alla pulizia e ridurre la frequenza con cui WordPress accede al database in primo luogo.

Ecco i punti chiave:

• Una dashboard di amministrazione lenta punta quasi sempre al database, non al tuo host o alle tue immagini. La dashboard bypassa la cache della pagina, quindi è il segnale più chiaro che hai.
• Revisioni dei post, transienti scaduti, dati orfani dei plugin e opzioni autoload gonfie sono i colpevoli più comuni, e tendono ad essere visibili in wp-admin.
• Query Monitor (gratuito) identifica quale plugin o query è il collo di bottiglia prima di eliminare qualsiasi cosa.
• DB Optimizer assegna al tuo database un punteggio di salute in cinque categorie e mostra un'anteprima completa di ciò che viene rimosso prima di confermare una pulizia.
• I dati autoloaded in wp_options dovrebbero rimanere sotto 1MB. Sopra questo limite, ogni caricamento di pagina porta un peso non necessario.
• La cache degli oggetti con Redis o Memcached può migliorare significativamente le dashboard lente che la cache della pagina non può toccare.
• Esegui un passaggio di pulizia prima di ogni backup o migrazione importante. Un database più piccolo significa un trasferimento più veloce e un file di backup più piccolo.

Indice

Cosa causa il rallentamento di un database WordPress?

Prima di addentrarti nelle correzioni, è utile sapere con cosa hai a che fare. I database WordPress rallentano per motivi prevedibili e la maggior parte dei siti ne ha più di uno contemporaneamente.

Revisioni dei post

Ogni volta che salvi o aggiorni un post, WordPress crea una nuova copia. Su un sito attivo, un singolo post può avere dozzine di copie di revisione presenti nel database a tempo indeterminato.

Sono invisibili ai visitatori ma aggiungono peso a ogni query contro la tabella dei post.

Transient scaduti

I plugin utilizzano i transienti per memorizzare temporaneamente nella cache i dati provenienti da chiamate API esterne e attività pianificate. Dovrebbero scadere ed eliminarsi automaticamente.

Spesso non lo fanno e i record scaduti si accumulano nella tabella wp_options molto tempo dopo aver esaurito il loro scopo.

Righe orfane e tabelle di plugin residue

Quando un plugin viene eliminato, i suoi dati di solito rimangono: campi personalizzati, metadati utente, metadati post e talvolta intere tabelle di database nominate come il plugin. Un sito che ha utilizzato una dozzina di plugin nel corso degli anni porta con sé i dati fantasma di ciascuno.

Dati autoloaded in wp_options

Le opzioni contrassegnate con autoload = yes vengono caricate ad ogni singola richiesta di pagina prima che WordPress renda qualsiasi cosa. I plugin che abusano di questo flag aggiungono peso a ogni caricamento di pagina, comprese le pagine che non hanno nulla a che fare con quel plugin.

I dati totali autoloaded dovrebbero rimanere sotto 1 MB. Molti siti lenti si trovano a 5 MB o più.

Frammentazione delle tabelle

Quando le righe vengono eliminate, MySQL non recupera automaticamente lo spazio che occupavano. Nel tempo, le tabelle diventano frammentate e MySQL deve lavorare di più per leggerle.

Questo è il motivo per cui l'esecuzione di un comando "Ottimizza Tabella" può velocizzare le cose anche quando i dati stessi sembrano puliti.

Query di plugin lente o eccessive

Alcuni plugin sono semplicemente scritti male. Eseguono dozzine di query per ogni caricamento di pagina, o interrogano colonne che non sono indicizzate, costringendo MySQL a scansionare intere tabelle riga per riga invece di saltare al record giusto.

Come correggere un database WordPress lento

Per correggere un database WordPress lento, dovrai trovare cosa lo rallenta, rimuovere il disordine che lo causa, correggere le tabelle che sopravvivono alla pulizia, quindi ridurre la frequenza con cui il database viene interrogato.

Ecco cosa farai:

• Passaggio 1: Identifica cosa sta rallentando il tuo database: usa il plugin gratuito Query Monitor per vedere ogni query che viene eseguita sul tuo sito, quanto tempo impiega ciascuna e quale plugin l'ha attivata.
• Passaggio 2: Pulisci il bloat del database: usa DB Optimizer per valutare il tuo database in cinque categorie di salute, visualizzare in anteprima esattamente cosa viene rimosso e pulirlo in sicurezza con una soglia di conservazione integrata.
• Passaggio 3: Gestisci le tabelle pesanti: correggi il bloat autoload in wp_options, abilita WooCommerce HPOS se pertinente, controlla le tabelle MyISAM che dovrebbero essere InnoDB e ottimizza l'overhead della tabella senza phpMyAdmin.
• Passaggio 4: Riduci la frequenza con cui WordPress interroga il database: aggiungi il page caching se non l'hai già fatto, quindi abilita l'object caching con Redis o Memcached per correggere la lentezza dell'amministrazione che il page caching non può raggiungere.

Passaggio 1: Identifica cosa sta rallentando il tuo database

Query Monitor è un plugin gratuito che mostra ogni query del database in esecuzione sulla pagina corrente, quanto tempo impiega ciascuna e quale plugin o tema l'ha attivata. Installalo dalla directory dei plugin di WordPress e attivalo come qualsiasi altro plugin.

Una volta attivo, appare un nuovo elemento nella barra degli strumenti di amministrazione che mostra il conteggio totale delle query e il tempo di caricamento della pagina per qualsiasi schermata ti trovi. Cliccaci sopra per aprire il pannello completo.

Vai alla scheda Database Queries. Cerca le query che impiegano più di 0,05 secondi e qualsiasi plugin che genera un numero insolitamente elevato di chiamate.

Query Monitor indica direttamente il plugin o il tema responsabile, quindi non devi indovinare.

Se un plugin genera 40 o più query per pagina o ha query costantemente superiori a 0,05 secondi, quello è il tuo collo di bottiglia. Disattivalo e testa di nuovo.

Se nessuna singola query spicca, il problema è un gonfiore generale distribuito nel database, non un attore specifico dannoso. Passa al Passaggio 2.

Una cosa da controllare prima di procedere: Query Monitor mostra solo il comportamento sulla pagina corrente. Eseguilo nella dashboard di amministrazione, su una pagina prodotto di WooCommerce se ne hai una e su un post standard.

La lentezza è spesso specifica della pagina e un problema di query nella pagina di checkout non apparirà mentre stai guardando la dashboard.

Passaggio 2: Pulisci il bloat del database

La maggior parte delle persone salta la pulizia del database perché non sa cosa sia sicuro eliminare. Questa esitazione è ragionevole. Eliminare la cosa sbagliata in un database non può essere annullato.

DB Optimizer risolve questo problema mostrandoti esattamente cosa c'è nel tuo database prima di rimuovere qualsiasi cosa. La prima cosa che vedrai è un punteggio di salute da 0 a 100.

Si suddivide in cinque categorie: overhead delle tabelle, transient, revisioni, dimensione autoload e elementi nel cestino. Ognuno ottiene una barra di avanzamento e un voto codificato a colori.

Verde significa che la categoria è in buona forma. Giallo significa che necessita di attenzione. Rosso significa che sta abbassando il tuo punteggio. Premi il pulsante Aggiorna Punteggio in qualsiasi momento per aggiornarlo.

Una volta che sai cosa sta abbassando il punteggio, vai alla scheda Pulizia. Una barra di riepilogo in alto mostra il numero di elementi disponibili per la pulizia e lo spazio totale recuperabile in tutto il tuo database.

Sotto, ogni tipo di pulizia (Post e Pagine, Commenti, Transient e Cache) mostra un conteggio di elementi e una dimensione stimata. Puoi vedere esattamente con cosa hai a che fare prima che qualcosa venga eliminato.

DB Optimizer utilizza per impostazione predefinita una soglia di conservazione di 7 giorni. Qualsiasi cosa creata nell'ultima settimana è off-limits, indipendentemente dai tipi di pulizia selezionati.

Se ti stai preparando per una migrazione e desideri una tabula rasa, abbassala. Se stai lavorando su un sito sensibile e desideri maggiore cautela, alzala. Impostala a 0 solo se vuoi pulire tutto indipendentemente dall'età. La tua preferenza viene salvata automaticamente.

Dopo la pulizia, aggiungi una riga al tuo file wp-config.php per limitare le revisioni future prima che si accumulino di nuovo:

define('WP_POST_REVISIONS', 3);

Aggiungila sopra la riga che dice “Questo è tutto, smetti di modificare!” Questo limita WordPress a conservare tre revisioni per post in futuro.

DB Optimizer gestisce ciò che è già presente. Questa riga impedisce che ritorni.

Passaggio 3: Gestisci le tabelle pesanti

La pulizia rimuove i dati non collegati, ma due tabelle specifiche causano lentezza continua anche dopo una pulizia approfondita: wp_options e wp_postmeta. Anche il motore di archiviazione utilizzato dal tuo database è importante qui.

Dati autoloaded in wp_options

DB Optimizer mostra la dimensione autoload come una delle sue cinque categorie di salute. Se è ancora superiore a 1 MB dopo aver eseguito la pulizia, un plugin sta attivamente scrivendo opzioni autoloadate ad ogni esecuzione. La pulizia rimuove le voci vecchie ma non può impedire l'aggiunta di nuove.

Usa la scheda Query Monitor per vedere cosa viene caricato automaticamente, quindi identifica quale plugin ne è responsabile. Disattivarlo o contattare il suo team di supporto è la soluzione.

Wp_postmeta

Questa tabella memorizza i dati dei campi personalizzati e cresce rapidamente nei siti con molti WooCommerce o ACF.

Query Monitor segnalerà le query su questa tabella se rappresenta un collo di bottiglia costante. Risolverlo a livello di query è territorio dello sviluppatore, ma sapere che è il problema è metà della battaglia.

Utenti WooCommerce: abilita HPOS

Se utilizzi WooCommerce, vai su WooCommerce » Impostazioni » Avanzate » Funzionalità e attiva l'opzione Archiviazione ordini ad alte prestazioni.

Questo sposta i dati degli ordini da wp_postmeta a tabelle dedicate e appositamente costruite. Può accelerare drasticamente le query degli ordini su qualsiasi negozio con più di qualche centinaio di ordini.

Dopo averla abilitata, WooCommerce potrebbe chiederti di migrare i dati degli ordini esistenti. Esegui la migrazione prima di procedere.

Motore di archiviazione: MyISAM vs. InnoDB

MyISAM blocca l'intera tabella del database durante ogni operazione di scrittura, causando code sotto qualsiasi carico di scrittura significativo. InnoDB blocca solo la riga specifica su cui si sta scrivendo.

WordPress ha impostato InnoDB come predefinito da MySQL 5.7, ma i siti migrati da ambienti di hosting più vecchi hanno ancora a volte tabelle MyISAM.

La scheda Tabelle di DB Optimizer mostra il motore di archiviazione per ogni tabella. Se vedi tabelle MyISAM, convertirle in InnoDB è una modifica SQL di una sola riga, ma vale la pena affidarla a uno sviluppatore o chiedere al tuo host se possono gestirla tramite il loro pannello di controllo.

Overhead delle tabelle

DB Optimizer evidenzia qualsiasi tabella che presenta overhead e mostra un pulsante Ottimizza accanto ad essa. Puoi gestirle individualmente o eliminare tutto l'overhead in una volta sola.

Esegui questo dopo la pulizia, poiché l'eliminazione delle righe è ciò che crea l'overhead in primo luogo.

Passaggio 4: Riduci la frequenza con cui WordPress interroga il database

Anche un database pulito e ottimizzato viene interrogato ad ogni caricamento di pagina. I livelli di caching intercettano queste query in modo che il database lavori meno nel complesso.

Il page caching salva l'output HTML completo di una pagina in modo che WordPress salti completamente il database per quella richiesta.

Se non hai un plugin di caching, aggiungine uno prima di tutto. WP Rocket, W3 Total Cache e LiteSpeed Cache gestiscono tutti questo aspetto. Il page caching è la modifica di maggior impatto che puoi apportare per i visitatori del frontend.

Dovresti anche abilitare l'object caching. L'object caching salva i risultati delle singole query del database nella memoria del server in modo che le query ripetute colpiscano la cache invece del database.

Le richieste di amministrazione, i checkout di WooCommerce e qualsiasi pagina che non può essere completamente memorizzata nella cache beneficiano di questo.

Chiedi al tuo host se Redis o Memcached sono disponibili. Molti host WordPress gestiti includono uno o entrambi.

Se Redis è disponibile, installa il plugin Redis Object Cache e segui le istruzioni di connessione del tuo host. Il plugin visualizza uno stato Connesso quando funziona correttamente.

Non installare Redis Object Cache a meno che il tuo host non fornisca effettivamente un server Redis. Senza una connessione attiva, il plugin genera errori e non offre alcun beneficio.

Opzionale: Comandi WP-CLI per correggere un database lento

Se gestisci WordPress dalla riga di comando, questi comandi coprono lo stesso terreno dei passaggi precedenti senza un'interfaccia plugin.

wp db optimize

Esegue l'utility di ottimizzazione di MySQL su ogni tabella del database.

wp transient delete --expired

Rimuove tutti i transienti scaduti da wp_options.

wp post delete $(wp post list --post_status=trash --format=ids)

Elimina definitivamente tutti i post attualmente nel cestino.

wp post delete $(wp post list --post_type='revision' --format=ids)

Elimina tutte le revisioni dei post memorizzate.

Esegui un backup con Duplicator prima di eseguire uno di questi comandi. Eseguono immediatamente senza alcun passaggio di anteprima e senza richiesta di conferma.

WP-CLI non fornisce il punteggio di salute, le soglie di conservazione o le anteprime per categoria che fornisce DB Optimizer. Ti offre solo un percorso più veloce per le stesse attività di pulizia.

Risoluzione dei problemi: quando il database è ancora lento

Se hai seguito tutti questi passaggi e il sito è ancora lento, è probabile che uno di questi scenari ne sia la causa.

Query Monitor non mostra colpevoli evidenti

Cosa vedi: ogni singola query è inferiore a 0,05 secondi ma la pagina continua a caricarsi lentamente.

Il problema potrebbe essere il volume totale delle query, non una singola query lenta. Duecento query da 0,01 secondi ciascuna aggiungono comunque due secondi completi di tempo del database prima che qualcosa venga visualizzato.

Controlla la barra di riepilogo in Query Monitor. Se il numero totale di query è superiore a 50-75 in una pagina standard, vale la pena indagare.

Disattiva i plugin uno alla volta, ricarica la pagina dopo ogni disattivazione e osserva il calo del conteggio. Il plugin che causa il calo maggiore è il tuo obiettivo.

La dimensione Autoload rimane alta dopo la pulizia

Cosa vedi: DB Optimizer mostra ancora una dimensione autoload superiore a 1 MB dopo aver eseguito la pulizia.

La pulizia rimuove le voci autoload scadute e orfane, ma non può impedire a un plugin di scriverne di nuove. Se il numero continua a salire, qualcosa sta attivamente aggiungendo al pool autoload ad ogni richiesta.

Query Monitor mostra ogni opzione che viene caricata automaticamente nella pagina corrente. Cerca voci di plugin che non riconosci o che non utilizzi attivamente, quindi disattiva tali plugin uno alla volta e aggiorna il punteggio.

Il checkout di WooCommerce è ancora lento dopo la pulizia

Cosa vedi: le pagine di checkout impiegano da tre a cinque secondi per caricarsi dopo la pulizia.

HPOS potrebbe essere abilitato ma la migrazione dei dati potrebbe non essere completa. Vai su WooCommerce » Stato » Strumenti e cerca un'opzione Migra dati ordini. Se è presente, eseguila.

Le migrazioni incomplete lasciano WordPress a leggere contemporaneamente da entrambe le strutture di tabelle, vecchia e nuova, il che è più lento di una sola delle due.

Se la migrazione è già completa, un plugin in conflitto potrebbe forzare WooCommerce a tornare alle tabelle degli ordini legacy. Disattiva i plugin uno alla volta e testa la velocità del checkout dopo ciascuno.

Object Caching mostra Connesso ma l'amministrazione è ancora lenta

Cosa vedi: il plugin Redis Object Cache mostra "Connesso" ma le pagine di amministrazione sono ancora lente.

È probabile che un plugin stia svuotando la cache degli oggetti ad ogni richiesta, il che vanifica lo scopo di averla. Apri Query Monitor e controlla la cache. Se il rapporto di cache hit è inferiore all'80%, qualcosa sta svuotando aggressivamente.

Identificalo disattivando i plugin in gruppi di due o tre, controllando il rapporto dopo ogni gruppo. Quando il rapporto di corrispondenza aumenta, l'ultimo gruppo che hai disattivato contiene il problema.

Nulla funziona

Se tutti e quattro i passaggi sono completi e le prestazioni non sono migliorate, il problema è probabilmente esterno al database stesso. Una memoria MySQL insufficiente su hosting condiviso costringe il server a utilizzare lo scambio su disco invece della RAM, cosa che nessuna pulizia risolverà.

Contatta il tuo host e chiedi specificamente dell'allocazione della memoria MySQL e se è disponibile il logging delle query lente lato server. Uno sviluppatore che esamina il log delle query lente può identificare problemi che Query Monitor non può rilevare.

Domande frequenti (FAQ)

Il tuo database non si pulirà da solo

Hai fatto qualcosa che la maggior parte dei proprietari di siti WordPress non fa mai: hai diagnosticato un collo di bottiglia del database, ripulito dati che si accumulano da anni, affrontato le tabelle specifiche che causano lentezza persistente e ridotto la frequenza con cui il database deve lavorare.

In futuro, esegui il controllo di integrità di DB Optimizer una volta al mese. Il bloat del database ritorna gradualmente e un controllo mensile impedisce che si accumuli.

E tieni presente che l'ottimizzazione modifica permanentemente il tuo database. Un backup prima di iniziare fa la differenza tra un errore correggibile e uno permanente.

Oltre 1,5 milioni di professionisti WordPress utilizzano Duplicator per eseguire il backup e migrare i propri siti. Il piano gratuito copre i backup completi del sito e richiede circa due minuti per la configurazione. Esegui l'upgrade per lo spazio di archiviazione cloud, i backup automatici e un plugin DB Optimizer gratuito con Duplicator Pro!

Se questa guida ti è stata utile, anche questi post meritano di essere aggiunti ai preferiti.

• Come ottimizzare il tuo database WordPress
• Ecco i passaggi per il ripristino del database di WordPress che ho eseguito personalmente
• Manutenzione del database di WordPress: Cosa fare settimanalmente, mensilmente e trimestralmente
• Come eseguire il backup di un database WordPress
• Il miglior plugin per l'ottimizzazione del database di WordPress che abbia mai usato (più 3 alternative)