Optimizare query meta în WordPress pentru performanță crescută

Răspunsul scurt este că metadatele în WordPress nu sunt concepute pentru a fi folosite pentru date relaționale. Obținerea postărilor pe baza mai multor condiții legate de metadatele lor nu este ideea din spatele metadatelor. Prin urmare, interogările, structurile tabelelor și indecșii nu sunt optimizați pentru acest lucru.

Răspunsul mai detaliat:

Ceea ce rezultă din interogarea ta de metadate este ceva de genul:

SELECT   wp_4_posts.* FROM wp_4_posts  
INNER JOIN wp_4_postmeta ON (wp_4_posts.ID = wp_4_postmeta.post_id)
INNER JOIN wp_4_postmeta AS mt1 ON (wp_4_posts.ID = mt1.post_id)
INNER JOIN wp_4_postmeta AS mt2 ON (wp_4_posts.ID = mt2.post_id)
INNER JOIN wp_4_postmeta AS mt3 ON (wp_4_posts.ID = mt3.post_id)
INNER JOIN wp_4_postmeta AS mt4 ON (wp_4_posts.ID = mt4.post_id) 
WHERE 1=1  
AND wp_4_posts.post_type = 'post' 
AND (wp_4_posts.post_status = 'publish' OR wp_4_posts.post_status = 'private') 
AND ( (wp_4_postmeta.meta_key = '_author' AND CAST(wp_4_postmeta.meta_value AS CHAR) = 'Test')
OR  (mt1.meta_key = '_publisher' AND CAST(mt1.meta_value AS CHAR) = 'Test')
OR  (mt2.meta_key = '_contributor_1' AND CAST(mt2.meta_value AS CHAR) = 'Test')
OR  (mt3.meta_key = '_contributor_2' AND CAST(mt3.meta_value AS CHAR) = 'Test')
OR  (mt4.meta_key = '_contributor_3' AND CAST(mt4.meta_value AS CHAR) = 'Test') ) GROUP BY wp_4_posts.ID ORDER BY wp_4_posts.post_date DESC

Să vedem cum gestionează MySQL această interogare (EXPLAIN):

    id      select_type     table           type    possible_keys                   key                     key_len ref                             rows    Extra
    1       SIMPLE          wp_4_posts      range   PRIMARY,type_status_date        type_status_date        124     NULL                            5       Using where; Using temporary; Using filesort
    1       SIMPLE          wp_4_postmeta   ref     post_id,meta_key                post_id                  8      wordpress.wp_4_posts.ID         1
    1       SIMPLE          mt1             ref     post_id,meta_key                post_id                  8      wordpress.wp_4_posts.ID         1
    1       SIMPLE          mt2             ref     post_id,meta_key                post_id                  8      wordpress.mt1.post_id           1       Using where
    1       SIMPLE          mt3             ref     post_id,meta_key                post_id                  8      wordpress.wp_4_posts.ID         1
    1       SIMPLE          mt4             ref     post_id,meta_key                post_id                  8      wordpress.wp_4_postmeta.post_id 1       Using where

Ce poți observa este că MySQL face o selecție pe wp_posts și alătură de 5 ori tabelul wp_postmeta. Tipul ref indică faptul că MySQL trebuie să examineze toate rândurile din acest tabel, potrivind indexul (post_id, meta_key) comparând o valoare de coloană neindexată cu clauza ta where, și asta pentru fiecare combinație de rânduri din tabelul anterior. Manualul MySQL precizează: »Dacă cheia folosită se potrivește doar cu câteva rânduri, acesta este un tip bun de alăturare.« Și aceasta este prima problemă: pe un sistem WordPress mediu, numărul de metadate pe postare poate crește ușor până la 30-40 de înregistrări sau mai mult. Cealaltă cheie posibilă, meta_key, crește odată cu numărul de postări. Deci, dacă ai 100 de postări și fiecare are o metadată _publisher, există 100 de rânduri cu această valoare ca meta_key în wp_postmeta, desigur.

Pentru a gestiona toate aceste rezultate posibile, MySQL creează un tabel temporar (using temporary). Dacă acest tabel devine prea mare, serverul îl stochează de obicei pe disc în loc de memorie. Un alt potențial punct de blocaj.

Posibile soluții

Așa cum este descris în răspunsurile existente, ai putea încerca să optimizezi interogarea pe cont propriu. Aceasta poate funcționa bine pentru nevoile tale, dar poate duce la probleme pe măsură ce tabelele de postări/metadate cresc.

Dar dacă dorești să folosești API-ul de interogare WordPress, ar trebui să iei în considerare utilizarea taxonomiilor pentru a stoca datele după care dorești să cauți postările.

Acest lucru poate fi puțin întârziat, dar am întâmpinat aceeași problemă. Când am construit un plugin pentru gestionarea căutării de proprietăți, opțiunea mea de căutare avansată interoga până la 20 de intrări meta diferite pentru fiecare articol pentru a găsi cele care se potrivesc cu criteriile de căutare.

Soluția mea a fost să interoghez direct baza de date folosind variabila globală $wpdb. Am interogat fiecare intrare meta individual și am stocat post_ids (ID-urile articolelor) care se potrivesc cu fiecare criteriu. Apoi am făcut o intersecție între fiecare set de rezultate potrivite pentru a obține post_ids care se potrivesc cu toate criteriile.

Cazul meu a fost oarecum simplu pentru că nu aveam elemente OR de luat în considerare, dar acestea ar putea fi incluse relativ ușor. În funcție de cât de complexă este interogarea ta, aceasta este o soluție funcțională și rapidă. Cu toate acestea, recunosc că este o opțiune inferioară în comparație cu posibilitatea de a face o interogare relațională adevărată.

Codul de mai jos a fost simplificat foarte mult față de ceea ce am folosit eu, dar poți înțelege ideea din el.

class property_search{

public function get_results($args){
    $potential_ids=[];
    foreach($args as $key=>$value){
        $potential_ids[$key]=$this->get_ids_by_query("
            SELECT post_id
            FROM wp_postmeta
            WHERE meta_key = '".$key."'
            AND CAST(meta_value AS UNSIGNED) > '".$value."'
        ");//ar trebui creat un operator nou pentru a gestiona fiecare tip de date și comparație
    }

    $ids=[];
    foreach($potential_ids as $key=>$temp_ids){
        if(count($ids)==0){
            $ids=$temp_ids;
        }else{
             $ids=array_intersect($ids,$temp_ids);
        }
    }

    $paged = (get_query_var('paged')) ? get_query_var('paged') : 1;
    $args = array(
        'posts_per_page'=> 50,
        'post_type'=>'property',
        'post_status'=>'publish',
        'paged'=>$paged,
        'post__in'=>$ids,
    );
    $search = new WP_Query($args);
    return $search;
}

public function get_ids_by_query($query){
    global $wpdb;
    $data=$wpdb->get_results($query,'ARRAY_A');
    $results=[];
    foreach($data as $entry){
        $results[]=$entry['post_id'];
    }
    return $results;
}

}

Tabelul wp_postmeta are indecși ineficienți. Iată o discuție pe această temă, împreună cu soluții recomandate:

http://mysql.rjweb.org/doc.php/index_cookbook_mysql#speeding_up_wp_postmeta

Interogările OR sunt foarte costisitoare.

Aveți prea multe chei, dar să presupunem că nu le puteți schimba acum. Cealaltă opțiune pe care o aveți, fără prea mult cod, este să modificați numărul de articole pe care le obțineți, schimbați 'posts_per_page' la 10, sau un număr mai mare, și observați cum se modifică performanța.