1. Установите запрос перед запуском WP_Query.
По-видимому, это самое важное, что следует иметь в виду при попытке свести к минимуму запросы к базе данных, поскольку единственная возможность изменить запрос - это, конечно, до его запуска в базе данных SQL.
Обычные запросы
Для нормального запроса WordPress использует wp()функцию, которая в свою очередь вызывает $wp->main( $query_vars ). «Переменные is_» из условных тегов устанавливаются перед их передачей WP_Query->get_posts(), что преобразует их в запрос к базе данных MySQL и, наконец, сохраняет их в объекте $ wp_query. Можно отфильтровать запрос до его фактического запуска в базе данных SQL .
pre_get_postsДействие перехватывает в этот процесс, что позволяет изменить запрос , прежде чем он передается WP_Query->get_posts().
Например, если вы хотите отфильтровать запрос для сообщений в категории «Избранные», вы должны использовать add_action( 'pre_get_posts', 'your_function_name' );и включать in_categoryусловный тег в your_function_name.
function your_function_name( $query ) {
if ( $query->in_category( 'featured' ) && $query->is_main_query() ) {
// Replace 123 with the category ID of the featured category.
$query->set( 'cat', '123' );
}
}
add_action( 'pre_get_posts', 'your_function_name' );
См. Плагин API / Справочник по действию / Предварительное получение сообщений «WordPress Codex
Запросы
страницы Что касается шаблонов страниц, таких как страница архива для категории «избранные», условные теги не будут работать из pre_get_postsфильтра. Например, вы не можете использовать is_categoryдля проверки страницы архива, потому что WP_Query не запущен.
Вместо этого вам придется изменить основной запрос для запросов на страницы, new WP_Queryкоторый будет выглядеть примерно так $query = new WP_Query( 'cat=123' );. Это запускает запрос с соответствующим аргументом, установленным с самого начала.
См. Class Reference / WP Query «WordPress Codex
2. Сохранение в базу данных
Вы можете использовать фильтр, wp_insert_post_dataобеспечивающий возврат только тех данных $, которые относятся к вашему типу записи wp_insert_post. Не забудьте включить условный оператор, чтобы проверить свой тип сообщения.
Плагин API / Ссылка на фильтр / wp вставить данные поста «WordPress Codex
Этот хук вызывается wp_insert_postфункцией, которая вызывается wp_update_post, когда вы обновляете свой пользовательский тип сообщения, обычно путем сохранения черновика или публикации сообщения.
Вы должны будете сами сравнить его, так как я не могу лично говорить о значимости оптимизации сокращения данных, которые обновляются в базе данных.
3. Влияют ли пользовательские типы сообщений на производительность?
По моему опыту, пользовательские типы записей являются мощным инструментом для управления контентом. Я не знаю другого способа управления постами всеми способами, которые позволили бы таким образом, чтобы использовать меньше ресурсов. Я бы лично сосредоточился на поиске способов сократить количество запросов, по возможности.
Раньше существовала проблема производительности, связанная со структурой постоянных ссылок, которая заставляла ее попадать, когда она начинается с текста, а не с числа. 3 Это было особенно проблематично для сайтов, на которых размещено большое количество страниц, но было решено с версии WordPress 3.3.
Я только поднимаю здесь постоянные ссылки, потому что слаг обычно является первой частью структуры постоянных ссылок, которая может повлиять или не повлиять на производительность до версии 3.3. Кроме того, я не знаю каких-либо проблем с производительностью, которые возникают из-за использования пользовательских типов записей.
Другие параметры производительности
Переходные процессы
Это не замена для минимизации количества запросов в вашем коде, но вы можете использовать set_transient для хранения запросов в течение некоторого времени, так что новые запросы не нужны. Вот пример, использованный в посте Дэйва Клемента . Также обратите внимание, что он рекомендует добавить save_postдействие для удаления переходного процесса при каждом обновлении данного типа записи.
<?php // IN THE SPOTLIGHT QUERY
if( false === ( $its_query = get_transient( 'its_query' ) ) ) {
$pttimestamp = time() + get_option('gmt_offset') * 60*60;
$its_query = new WP_Query( array(
'post_type' => 'spotlight',
'posts_per_page' => 1,
'post__not_in' => $do_not_duplicate,
'meta_query' => array(
array(
'key' => '_hpc_spotlight_end_time',
'value' => $pttimestamp,
'compare' => '>'
)
)
) );
set_transient( 'its_query', $its_query, 60*60*4 );
}
if( have_posts() ) { // HIDE SECTION IF NO CURRENT ITS FEATURE ?>
// LOOP GOES HERE: NOT IMPORTANT TO EXAMPLE
<?php } ?>
Дополнительная оптимизация запросов
Томас Гриффин имеет несколько хороших советов в своем учебнике по оптимизации запросов WordPress . Вот краткий список его предложений:
Установите 'cache_results' => falseв одноразовых запросах, если ваш сервер не использует постоянное кэширование, такое как Memcached. Разовые запросы описываются как «запросы, которые используются для отображения небольших объемов данных. Возможно, вы просто хотите отобразить заголовки связанных сообщений, относящиеся к текущему сообщению, или вы можете отобразить раскрывающийся список сообщений, которые можно выбрать для конкретный параметр настройки. "
Его пример: $query = get_posts( array( 'posts_per_page' => 1,
'cache_results' => false ) );
Установите, 'no_found_rows' => trueгде нумерация страниц не требуется. Это «обойдёт MySQL, подсчитывая результаты, чтобы увидеть, нужно ли разбивать на страницы или нет».
Его пример: $query = new WP_Query( array( 'posts_per_page' => 1,
'no_found_rows' => true ) );
Запрос для почтовых идентификаторов только если это все , что вам нужно 'fields' => 'ids'
в get_posts. Это должно значительно сократить объем возвращаемых данных, что довольно много для каждого поста, если вы посмотрите на
описание базы данных «WordPress Codex
Его пример: $query = get_posts( array( 'posts_per_page' => 1,
'fields' => 'ids' ) );
В дополнение к этому последнему совету, те же рассуждения могут быть применены, когда вам нужно только одно или несколько полей сообщений с помощью get_post_field .
Наличие четкого понимания того, как работает запрос, очень важно. Чем конкретнее вы можете быть с вашими запросами, тем меньше работы вы будете требовать от базы данных SQL. Это означает, что существует множество возможностей для управления запросами к базе данных. Будьте осторожны с пользовательскими запросами в отношении того, где они выполняются (это страница администратора?), Используйте правильную очистку в прямых запросах и старайтесь использовать встроенные функции WordPress, где это позволяет достичь той же производительности.