Мета-запрос работает очень медленно

Короткий ответ: метаданные в WordPress не предназначены для хранения реляционных данных. Выборка записей по нескольким условиям их метаданных противоречит изначальной концепции метаданных. Поэтому структура таблиц, запросы и индексы не оптимизированы для таких операций.

Более развернутый ответ:

Ваш мета-запрос приводит к выполнению примерно такого SQL-запроса:

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

Давайте посмотрим, как MySQL обрабатывает этот запрос (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

Здесь мы видим, что MySQL делает выборку из wp_posts и соединяет таблицу wp_postmeta пять раз. Тип соединения ref означает, что MySQL должен проверить все строки в этой таблице, сопоставляя индекс (post_id, meta_key) и сравнивая значения неиндексированных столбцов с условием where, причем для каждой комбинации строк из предыдущей таблицы. В документации MySQL сказано: «Если используемый ключ соответствует лишь нескольким строкам, это хороший тип соединения». И это первая проблема: в типичной системе WordPress количество метаданных на одну запись может легко достигать 30-40 или более. Другой возможный ключ meta_key увеличивается вместе с количеством записей. Так, если у вас 100 записей и у каждой есть метаполе _publisher, то в таблице wp_postmeta будет 100 строк с этим значением в meta_key.

Для обработки всех этих возможных результатов MySQL создает временную таблицу (using temporary). Если эта таблица становится слишком большой, сервер обычно сохраняет ее на диск вместо памяти. Это еще одно потенциальное узкое место.

Возможные решения

Как описано в существующих ответах, вы можете попытаться оптимизировать запрос самостоятельно. Это может хорошо работать для ваших текущих нужд, но может вызвать проблемы по мере роста таблиц post/postmeta.

Но если вы хотите использовать WordPress Query API, вам следует рассмотреть возможность использования таксономий для хранения данных, по которым вы хотите осуществлять поиск записей.

Возможно, это немного запоздалое решение, но я столкнулся с той же проблемой. При создании плагина для поиска объектов недвижимости мой расширенный поиск выполнял запросы к 20 различным мета-полям для каждого поста, чтобы найти соответствующие критериям поиска.

Моим решением был прямой запрос к базе данных с использованием глобальной переменной $wpdb. Я запрашивал каждое мета-поле отдельно и сохранял post_ids постов, соответствующих каждому критерию. Затем я выполнял пересечение всех найденных наборов, чтобы получить post_ids, соответствующие всем критериям.

Мой случай был относительно простым, так как у меня не было элементов OR, которые нужно было учитывать, но их можно было бы довольно легко добавить. В зависимости от сложности вашего запроса, это рабочее и быстрое решение. Хотя, признаю, это не лучший вариант по сравнению с выполнением истинного реляционного запроса.

Приведенный ниже код сильно упрощен по сравнению с тем, что я использовал, но он дает общее представление.

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."'
        ");//для каждого типа данных и сравнения нужно создать новый оператор.
    }

    $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;
}

}

Таблица wp_postmeta имеет неэффективные индексы. Вот обсуждение этой проблемы и рекомендуемые решения:

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

Операторы OR очень дорогостоящие.

У вас слишком много ключей, но предположим, что сейчас это нельзя изменить. Другой вариант, который можно реализовать без большого объема кодирования, — это изменить количество получаемых записей, заменив 'posts_per_page' на 10 или большее число, и посмотреть, как это повлияет на производительность.