Query lenta per la tabella wp_options

Ho monitorato il registro delle query lente del sito basato su WP (con il valore predefinito di a long_query_time impostato su 10) e ho notato che spesso viene registrata la seguente query:

# User@Host: root[root] @ localhost []
# Query_time: 0  Lock_time: 0  Rows_sent: 394  Rows_examined: 458
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

Non capisco come una tabella così piccola possa richiedere così tanto tempo per essere eseguita. Questo è solo un sintomo di qualche altro problema? (Attualmente in esecuzione Moodle, phpbb e WP su una macchina virtuale dedicata).

Aggiornamento : il motivo per cui la query viene registrata è che non utilizza un indice . Il tempo di query è 0, cioè in realtà viene eseguito rapidamente. È possibile disattivare l'opzione "log-query-not-using-indexes" se non si desidera che vengano registrati.

La tabella wp_options non ha alcun indice al caricamento automatico, quindi la query finisce per eseguire una scansione completa della tabella. In generale quella tabella non dovrebbe diventare troppo grande, quindi non è un problema, ma immagino che sia successo in qualche modo nel tuo caso.

L'aggiunta di un indice potrebbe risolvere il problema, ma come sottolineato da TheDeadMedic nei commenti, potrebbe non essere se i valori del caricamento automatico sono la maggioranza sì o distribuiti uniformemente tra sì e no:

Innanzitutto, esegui questa query per vedere come appare la distribuzione:

SELECT COUNT(*), autoload FROM wp_options GROUP BY autoload;

se la maggior parte di essi è impostata su "no", per ora puoi risolvere il problema aggiungendo un indice al caricamento automatico.

ALTER TABLE wp_options ADD INDEX (`autoload`);

Tuttavia, potresti voler arrivare alla fine del perché quella tabella è diventata troppo grande. Forse qualche plugin scritto male che fa qualcosa di sospetto.

Mi sono imbattuto nella query menzionata in mytop in esecuzione sul mio server alcuni giorni fa - e in realtà ci è voluto del tempo (circa 10 secondi) per ogni query! Quindi ci sono situazioni del mondo reale in cui wp_options potrebbe crescere fino a dimensioni problematiche. Nel mio caso sospetto che il plug-in di cache Cachify sia responsabile del gonfiore di wp_options.

Dati di questo particolare wp_options:

5,309 rows
130MB of data

Come soluzione, ho aggiunto un indice simile alla soluzione pubblicata da Vinay Pai, che ha risolto il problema in modo impeccabile.

La mia tabella wp_options aveva solo circa 235 righe di dati. Ho provato a indicizzare la tabella, ma non ha aiutato.

Si scopre che circa 150 opzioni temporanee sono state inserite nella tabella, ma non sono state eliminate automaticamente.

Non so se sia correlato o meno, ma ho esaminato i miei file /var/log/apache2/access.log e ho notato che più server Amazon Web Services (presumibilmente compromessi) (indirizzi IP che iniziano con 54. XXX e 32.XXX) avevano tentato di sfruttare /~web-root-dir/xmlrpc.php.

Dopo un po 'di risoluzione dei problemi, ho richiesto la tabella wp_options per i nomi delle opzioni che contenevano "transitorio"

seleziona * da wp_options dove option_name come '% transient %';

Uno dei campi restituiti da questa query è 'option_value' che ha un tipo di dati di LONGTEXT. Secondo i documenti mySQL, un campo LONGTEXT (per ogni riga) può contenere fino a 4 Gigabyte di dati.

Quando ho eseguito la query, alcune delle righe (ricordate che stavano lavorando con quelle contenenti "transitorio") avevano enormi quantità di dati nel campo option_value. Guardando attraverso i risultati, ho anche visto quelli che sembravano tentativi di iniettare comandi nel processo wp-cron con la speranza che sarebbero stati eseguiti durante i cicli cron.

La mia soluzione era eliminare tutte le righe "transitorie". Ciò non danneggerà il server poiché le righe "transitorie" verranno automaticamente ripopolate (se si suppone che siano lì).

Dopo aver fatto ciò, il server è stato nuovamente reattivo.

Query per eliminare queste righe:

ELIMINA da wp_options dove option_name come '% transient %';

Ho aggiunto anche l'indirizzo IP AWS / 8 superblock al mio firewall (-: