Come mai la tabella `wp_options` non ha un indice su` autoload`?

All'inizio di ogni pagina servita da WordPress, c'è una chiamata MySQL per recuperare le opzioni:

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

Poiché non esiste alcun indice sulla autoloadcolonna, MySQL deve cercare TUTTE le righe.

Mi sono anche imbattuto nel commento di questa risposta dicendo che non ci sarebbe stato alcun miglioramento delle prestazioni anche se ci fosse un indice.

Nella mia applicazione, ho usato molti valori temporanei per sostituire la sessione. Hanno funzionato benissimo e ho le mie routine di raccolta dei rifiuti. Ho notato che nella wp_optionstabella, tutti i miei valori transitori (quelli che iniziano con _transient_) hanno tutti autoload=no. Mi aspetto che il numero di righe della mia wp_optionstabella aumenti con l'aumentare del numero di utenti simultanei.

Vorrei sapere perché il tavolo è stato progettato in questo modo. E dovrei creare un indice per il mio caso particolare?

Non esiste un indice perché la necessità non è mai stata abbastanza forte.

Nel ticket n. 14258 è stato suggerito, ma poiché la maggior parte delle opzioni utilizza autoload=yesper impostazione predefinita, l'indice verrebbe comunque ignorato.

C'è anche il ticket ancora aperto # 24044 _Aggiungi indice a wp_options per aiutare / migliorare le prestazioni_ .

Penso che dovresti creare un indice. Sopravviverà agli aggiornamenti. Potrebbe non aiutare la tua esibizione, ma potresti aggiungere dati statistici reali a quel biglietto.

Aggiornamento novembre 2019

L'indice è stato aggiunto a WordPress 5.3. Infine. Vedi il ticket # 24044 sopra menzionato e le note dello sviluppatore per il rilascio .

Nota che se hai un indice esistente con lo stesso nome, riceverai un avviso durante l'aggiornamento.

Dal changeset :

La maggior parte dei siti non sarà interessata da questa modifica, ma quelli con un numero elevato di righe wp_options, solo un numero limitato di quelli autoloadimpostati, vedranno un significativo miglioramento delle prestazioni.
I siti con un gran numero di righe wp_options, con molte delle quali autoloadimpostate, sfortunatamente vedranno una penalità prestazionale in aggiunta alle query già molto lente che stanno eseguendo, ma questa dovrebbe essere la minoranza dei casi.

Sto eseguendo 3 blog WP su un'istanza di grandi dimensioni di Debian Squeeze e stavo indagando sul perché mysql fosse bloccato su quell'host con un utilizzo della CPU del 200% e carico di sistema tra 3 e 6. Guardando un 'show process list' all'interno di mysql, abbiamo capito che La tabella wp_option è stata coinvolta in questo problema, quindi abbiamo eseguito:

alter table wp_options add index autoload_idx(`autoload`);

Dopo questa operazione il carico mysql, come mostrato in alto, è drasticamente sceso all'1% e la media del carico dell'istanza è ora di 0,10.

Stiamo usando alcuni plugin in modo che ci possa essere un loop da qualche parte nel codice, e questa potrebbe essere una situazione particolare, ma nel nostro caso il cambiamento nelle prestazioni è assolutamente sorprendente.

La nostra tabella wp_options ha 347 righe.

Mentre @fuxia ha accettato tocchi di risposta su alcuni motivi "rivendicati" (la maggior parte dei quali sono stati rivendicati dai dipendenti di Automattic su vari biglietti Trac, ecc.), Il motivo alla base di WordPress Core che non include un indice per le opzioni di caricamento automatico all'interno della wp_optionstabella è che Automattic era preoccupato che avrebbe avuto un impatto negativo sulle prestazioni dei database MySQL che utilizzavano ancora il motore MyISAM.

In particolare, hanno indicato il sito Web WordPress.org stesso, essendo un database molto vecchio / complesso, come un sito Web di esempio le cui prestazioni sarebbero danneggiate da un tale indice.

Quasi tutti gli altri motivi per non aver aggiunto l'indice negli ultimi 9 anni (sì, dal 2010 nel caso del biglietto Trac n. 14258 e dal 2013 nel caso del biglietto Trac n. 24044 ) sono state ripetutamente dimostrate errate da dozzine di membri del La comunità di WordPress, tuttavia i dipendenti di Automattic coinvolti hanno ripetutamente ignorato diversi test di benchmark indipendenti e sono tornati a menzionare le preoccupazioni di MyISAM.

Per fortuna, a fine 2019 con PHP 7.2 ora la versione "predefinita" raccomandata da WordPress Core e con il motore InnoDB ora predefinito nelle versioni di MySQL dopo la 5.5 , e con continue pressioni da parte di vari sviluppatori tra cui @DanBUK che ha continuato a occuparsi del problema per anni , Automattic ha finalmente ceduto e ha deciso di aggiungere l'indice di caricamento automatico a partire da WordPress 5.3+ a novembre 2019.

Noi di LittleBizzy avevamo lanciato il primo plugin noto che aggiungeva automaticamente l'indice se non esisteva, che è ancora disponibile su GitHub e scaricato regolarmente. Nota che NON devi PIÙ installare tali plugin sul tuo stack WordPress se esegui WP Core 5.3 + ...