Ci sono molte cattive abitudini che gli sviluppatori di WordPress dovrebbero evitare. Alcuni di questi includono l’uso dell’asterisco (*) per query SELECT , query ridondanti e, soprattutto, non avere abbastanza familiaritร con SQL.
Dopo anni di sviluppo su siti Web aziendali, gli sviluppatori spesso si pongono le seguenti domande:
- Perchรฉ non conoscevo questo metodo prima?
- Come potevo cavarmela prima?
La maggior parte degli sviluppatori che lavorano su WordPress riconosceranno che WordPress ha:
- Problemi di ottimizzazione costanti
- Problemi di scalabilitร che possono causare interruzioni del sito
- Plugin di terze parti che creano carichi di database elevati
ร pratica comune per uno sviluppatore di WordPress limitare la quantitร di plugin installati e attivati
L’argomento dell’ottimizzazione delle prestazioni puรฒ essere un argomento molto ampio da trattare. Invece di affrontare tutto in una volta, cercherรฒ di affrontare una query di impaginazione che ha creato problemi di scalabilitร per molti sviluppatori di WordPress. Questa รจ una query che vediamo spesso quando sviluppiamo su un sito WordPress.
Invece di dare immediatamente la soluzione, facciamo questo esercizio insieme.
Prenditi un momento e identifica 10 cose che puoi ottimizzare per questa seguente query:
SELECT SQL_CALC_FOUND_ROWS wp_posts.*, wp_postmeta.* FROM wp_posts INNER JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id) INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) WHERE 1=1 AND ( wp_term_relationships.term_taxonomy_id IN (554) ) AND wp_posts.post_type = 'post' AND (wp_posts.post_status != 'draft' || wp_posts.post_status <> 'private' || wp_posts.post_status != 'trash') AND CAST(wp_postmeta.meta_value AS CHAR) = 'episodes' GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 10; SELECT FOUND_ROWS();
Ecco un approccio migliore:
-
- 1. wp_posts.* => wp_posts.post_title, wp_posts.post_content, wp_posts.post_name, wp_posts.post_date, wp_postmeta.meta_key, wp_postmeta.meta_valueElenca solo le colonne di cui hai bisogno. Piรน colonne hai elencato, piรน grande diventa il tuo oggetto per la memoria.
- 2. WHERE 1=1 sarร sempre vero. Questa รจ una clausola ridondante. Ho sempre seguito la filosofia di mantenere le cose brevi e semplici! Segui il principio KISS. Se stai costruendo una clausola WHERE al volo e non sei sicuro di aver bisogno di espressioni aggiuntive nella clausola WHERE , un 1=1 alla fine assicura che creerai una clausola WHERE valida in modo che l’istruzione SELECT non esploda.
- 3. wp_term_relationships.term_taxonomy_id IN (554)Per questa specifica affermazione, รจ inclusa solo 1 tassonomia. L’uso diretto di ‘=’ รจ il migliore per le prestazioni, seguito da IN. Se sono presenti piรน di 2 tassonomie da chiamare, utilizzare IN . OR รจ il piรน lento.
- 4. (wp_posts.post_status != ‘draft’ || wp_posts.post_status <> ‘private’ || wp_posts.post_status != ‘trash’)!= AND <> sono entrambi terribili per le prestazioni, puoi ottenere gli stessi risultati usando wp_posts.post_status = ‘publish’ .
- 5. CAST(wp_postmeta.meta_value AS CHAR) = ‘episodes’Questo รจ complicato perchรฉ meta_value รจ un tipo LONGTEXT e non รจ indicizzato dallo schema del database. L’utilizzo di questa coppia chiave/valore รจ leggermente piรน pesante in termini di risorse rispetto a meta_key o post_id nella tabella wp_postmeta .
- 6. GROUP BY wp_posts.IDL’uso di GROUP BY puรฒ richiedere prestazioni elevate. Immagina l’algoritmo di ordinamento che deve essere eseguito per ottenere il set di dati di ritorno corretto.
- 7. ORDER BY wp_posts.post_date DESC.ASC รจ la clausola ORDER BY predefinita . Il DESC sta sostanzialmente invertendo l’ordine cronologicamente, richiedendo l’esecuzione di un algoritmo aggiuntivo.
- 8. LIMIT 0, 10L’uso del metodo offset puรฒ essere pessimo per le prestazioni. MySQL รจ in genere inadeguato per offset elevati . Immagina lo scenario LIMIT 200000, 10 . Questo puรฒ essere problematico quando si impagina su una tabella intera memorizzando tutte le righe in memoria. Prendi in considerazione l’idea di incapsulare la query per consentire al sistema di leggere alcune righe alla volta. Una soluzione consiste nell’utilizzare un ID indicizzato “autoincrement” come alternativa.
- 9. ‘OR’ รจ moderatamente piรน veloce in una frazione di secondo rispetto a ‘||’. Un altro vantaggio รจ la leggibilitร .
- 10. SELECT FOUND_ROWS()Esecuzione di query inutili. Ciรฒ avrebbe potuto essere ottenuto con una singola query efficiente.
Spero che questa prima parte della serie di prestazioni di WordPress ti sia piaciuta. Resta sintonizzato per la seconda parte.