Как найти и отключить лишние запросы к базе данных в WordPress

Если сайт на WordPress стал заметно тяжелее, а на хостинге растет время ответа, причина не всегда в «медленном сервере». Часто проблема в том, что тема, плагин или кастомный код делают лишние запросы к базе данных на каждой странице: повторно тянут одни и те же опции, грузят мета-данные там, где они не нужны, или запускают запросы внутри цикла без кеширования.

Ниже — рабочая схема, как найти источник лишних запросов, отключить его точечно и проверить, что сайт действительно стал вести себя лучше. Без выдуманных хуков и без магии.

Когда стоит искать лишние запросы к БД

Симптомы обычно похожи:

• страницы открываются нормально на пустом кэше, но заметно тормозят под нагрузкой;
• в админке долго открываются списки записей, редактор или настройки плагинов;
• после отключения части плагинов сайт сразу начинает отвечать быстрее;
• в логах MySQL видно много однотипных SELECT по одним и тем же таблицам;
• объектный кеш не используется, хотя запросов много и они повторяются.

Важно не путать лишние запросы с большим количеством запросов вообще. Для WordPress нормально делать десятки запросов на страницу. Проблема начинается, когда одни и те же данные запрашиваются снова и снова, хотя их можно было бы взять из кеша или вообще не запрашивать на этом шаблоне.

Диагностика: где искать источник нагрузки

Сначала нужно понять, это тема, плагин или собственный код. Самый практичный путь — смотреть не на абстрактную «производительность», а на конкретные SQL-запросы и место, где они запускаются.

1. Включите логирование запросов в разработке

Для локальной среды или staging можно временно включить SAVEQUERIES. WordPress начнет сохранять список запросов, время выполнения и стек вызовов. На боевом сайте это лучше не держать постоянно: память и накладные расходы будут лишними.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'SAVEQUERIES', true );

После этого можно посмотреть, какие запросы повторяются чаще всего. Если у вас есть доступ к отладочному плагину или собственному коду, полезно вывести массив $wpdb->queries в лог только на тестовом стенде.

2. Проверьте, не дублируются ли одни и те же данные в шаблоне

Частая ошибка — несколько вызовов get_option(), get_post_meta() или get_term_meta() в одном и том же шаблоне для одних и тех же ID. WordPress часть данных кеширует, но если код написан неаккуратно, запросы все равно могут повторяться из-за разных аргументов или вызовов внутри циклов.

Пример типичной проблемы:

<?php
foreach ( $posts as $post ) {
    $rating = get_post_meta( $post->ID, 'rating', true );
    $author = get_post_meta( $post->ID, 'author_name', true );
    $source = get_post_meta( $post->ID, 'source_name', true );
}

Если метаданных много, лучше заранее получить нужные записи или хотя бы не дергать одни и те же значения несколько раз в одном проходе.

3. Смотрите на тяжелые места через Query Monitor или аналогичный инструмент

На практике удобнее всего сначала найти проблемный запрос через отладочный плагин, а потом уже идти в код. Важно не просто увидеть «много запросов», а понять, какой файл и какая функция их породили. Это экономит время: вы правите не весь сайт, а конкретную точку.

Пошаговое решение: как отключить лишние запросы

Шаг 1. Уберите повторные вызовы в одном запросе

Если данные используются несколько раз, сохраните их в переменную. Это банально, но в реальных темах именно здесь часто теряется производительность.

<?php
$post_id = get_the_ID();
$rating  = get_post_meta( $post_id, 'rating', true );
$source  = get_post_meta( $post_id, 'source_name', true );

if ( $rating ) {
    echo '<span class="rating">' . esc_html( $rating ) . '</span>';
}

if ( $source ) {
    echo '<span class="source">' . esc_html( $source ) . '</span>';
}

Если значение используется в нескольких местах шаблона, не вызывайте функцию повторно в каждом блоке.

Шаг 2. Кешируйте результат там, где данные меняются редко

Для данных, которые не обновляются на каждом запросе, используйте transient или объектный кеш. Это особенно полезно для сложных выборок по WP_Query или для агрегации данных из нескольких таблиц.

<?php
function wpdebug_get_popular_posts_ids() {
    $cache_key = 'wpdebug_popular_posts_ids';
    $ids = get_transient( $cache_key );

    if ( false !== $ids ) {
        return $ids;
    }

    $query = new WP_Query( array(
        'post_type'      => 'post',
        'posts_per_page' => 10,
        'meta_key'       => 'views_count',
        'orderby'        => 'meta_value_num',
        'order'          => 'DESC',
        'fields'         => 'ids',
        'no_found_rows'  => true,
    ) );

    $ids = $query->posts;
    set_transient( $cache_key, $ids, HOUR_IN_SECONDS );

    return $ids;
}

Здесь важны две вещи: fields => 'ids' и no_found_rows => true. Если вам нужны только ID, не тащите полные объекты постов и не заставляйте WordPress считать общее количество строк без необходимости.

Шаг 3. Оптимизируйте запросы в WP_Query

Если проблема в кастомном запросе, проверьте аргументы. Иногда лишняя нагрузка появляется из-за параметров, которые не нужны на конкретной странице.

• no_found_rows => true — если пагинация не нужна;
• update_post_meta_cache => false — если мета не используется;
• update_post_term_cache => false — если термины не нужны;
• fields => 'ids' — если нужны только идентификаторы;
• ограничение posts_per_page до реального минимума.

<?php
$q = new WP_Query( array(
    'post_type'              => 'post',
    'posts_per_page'         => 5,
    'no_found_rows'          => true,
    'update_post_meta_cache' => false,
    'update_post_term_cache' => false,
    'fields'                 => 'ids',
) );

Шаг 4. Отключите лишние запросы в плагине или теме точечно

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

Для собственных шаблонов полезно вынести тяжелые выборки в отдельную функцию и использовать ее только там, где данные действительно нужны. Это проще сопровождать, чем размазывать запросы по файлам темы.

Как проверить, что решение сработало

После правки не ограничивайтесь ощущением «стало быстрее». Нужна проверка по фактам:

• сравните количество SQL-запросов до и после на одной и той же странице;
• посмотрите, исчезли ли повторяющиеся запросы с одинаковыми аргументами;
• проверьте, не сломалась ли пагинация, фильтры и вывод связанных данных;
• откройте страницу в режиме без кэша, чтобы увидеть реальную нагрузку;
• посмотрите логи PHP и MySQL на предмет новых ошибок.

Если вы использовали transient, проверьте и сценарий обновления данных. Например, после изменения записи кеш должен сбрасываться, иначе сайт будет показывать устаревшую информацию.

<?php
add_action( 'save_post', function( $post_id ) {
    delete_transient( 'wpdebug_popular_posts_ids' );
} );

Частые ошибки и как их исправить

Слишком агрессивное кеширование

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

Отключили мета- или термокеш, а потом удивились новым запросам

Параметры update_post_meta_cache и update_post_term_cache стоит отключать только если вы точно не используете эти данные в шаблоне. Иначе WordPress начнет делать дополнительные запросы уже при первом обращении к мета-данным или терминам.

Проверяли только главную страницу

На главной все может выглядеть нормально, а на архиве, странице автора или в поиске — совсем другая картина. Лишние запросы часто всплывают именно на нестандартных шаблонах.

Смотрели только на количество запросов, а не на их источник

Иногда один тяжелый запрос хуже десяти простых. Поэтому важно смотреть не только на число, но и на конкретный SQL, таблицу и функцию, которая его запускает.

Практические советы по безопасности и производительности

Если вы добавляете отладку, не оставляйте SAVEQUERIES и подробный лог на продакшене. Это лишняя нагрузка и лишние данные в логах. Для боевого сайта лучше использовать точечную диагностику и отключать ее сразу после проверки.

Если правите тему или плагин, делайте это в дочерней теме или в собственном мини-плагине. Так обновление не затрет исправления. Для сложных SEO- и технических правок иногда удобнее использовать отдельный слой оптимизации, чем постоянно редактировать шаблоны вручную.

Если нужно системно чистить дубли, лишние метаданные и технический мусор, можно посмотреть в сторону Clearfy Pro, но только как на инструмент для конкретной задачи, а не замену нормальной диагностики кода.

Мини-чек-лист перед выкладкой на прод

• проверил повторяющиеся запросы на тестовом стенде;
• убрал лишние вызовы get_post_meta(), get_option() и похожих функций в циклах;
• добавил кеш только там, где данные не меняются на каждом запросе;
• проверил сброс кеша после сохранения записи или настроек;
• сравнил поведение на главной, архиве и одиночной записи;
• убрал отладочные константы перед переносом на продакшен.

Если после этих шагов сайт все еще делает слишком много запросов, значит источник, скорее всего, глубже: в стороннем плагине, нестандартном шаблоне или в цепочке фильтров, которая запускается чаще, чем кажется. Тогда уже имеет смысл идти от конкретного SQL к конкретной функции, а не пытаться оптимизировать WordPress «в целом».