Медленный запрос в WordPress: как найти причину тормозов сайта и доказать её

Медленный запрос в WordPress может замедлять страницы, корзину и оформление заказа. Найдите источник задержки с помощью профилирования, логов MySQL и анализа SQL. Разберём, как получить измеримые доказательства и устранить проблему без случайных правок.

Почему медленный запрос в WordPress сложно обнаружить

Сайт открывается пять секунд. Вы отключаете плагины, меняете тему и очищаете кеш. Скорость почти не меняется. Знакомая ситуация?

Проблема может находиться на разных уровнях:

• PHP долго выполняет код.
• MySQL обрабатывает неоптимальный SQL-запрос.
• Плагин обращается к внешнему API.
• Сервер ограничивает ресурсы PHP или базы данных.
• Кеш не срабатывает для конкретной страницы.

Эти причины требуют разных решений. Поэтому сначала соберите данные, а затем меняйте код.

Важно: медленная страница не обязательно означает медленный SQL-запрос. Например, PHP может ждать ответ платёжного сервиса. Без измерений легко исправлять не ту причину.

Какие симптомы указывают на проблему с базой данных

Обратите внимание на следующие признаки:

• Страницы каталога работают медленнее главной.
• Админ-панель зависает при открытии списка записей.
• Поиск товаров занимает несколько секунд.
• Корзина тормозит после добавления товаров.
• В журналах появляются сообщения о превышении времени выполнения.
• При росте нагрузки сайт начинает отвечать значительно медленнее.

Один симптом ничего не доказывает. Однако несколько совпадений помогают выбрать направление диагностики.

Как найти медленный запрос в WordPress с помощью Query Monitor

Для первого этапа подойдёт плагин Query Monitor. Он показывает SQL-запросы, время выполнения, вызывающий код и ошибки PHP.

Шаг 1. Установите инструмент диагностики

Установите Query Monitor из официального каталога WordPress. Выполните проверку на тестовом сайте или в период низкой нагрузки.

Затем откройте страницу, которая тормозит. Авторизованному администратору WordPress покажет панель диагностики.

В меню Query Monitor изучите разделы:

• Queries by component — запросы по компонентам.
• Queries by caller — запросы по вызывающему коду.
• Database Queries — список обращений к базе данных.
• HTTP API Calls — внешние HTTP-запросы.
• PHP Errors — предупреждения и ошибки PHP.

Названия и доступность отдельных разделов зависят от версии инструмента.

Шаг 2. Найдите подозрительный запрос

Сначала посмотрите общее время работы базы данных. Затем изучите отдельные запросы.

Допустим, каталог товаров открывается за 2,8 секунды. Query Monitor показывает, что SQL-запросы заняли 1,9 секунды. Среди них один запрос выполняется 1,2 секунды.

Это уже полезная зацепка. Но пока не доказано, что именно этот запрос определяет скорость страницы.

Проверьте три параметра:

1. Время выполнения. Сколько занимает запрос?
2. Частота вызова. Выполняется ли он один раз или сотни раз?
3. Источник. Какой плагин, тема или участок кода его запускает?

Особенно опасны повторяющиеся запросы. Один запрос за 15 мс кажется безобидным. Но 200 таких запросов потребуют около трёх секунд суммарного времени базы данных, если они выполняются последовательно и не перекрываются.

Шаг 3. Определите виновный компонент

Предположим, медленный запрос вызывает плагин фильтрации товаров. Вы открываете раздел Queries by Component и находите компонент плагина.

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

Результат: вместо предположения «WordPress тормозит» у вас появляется конкретная цепочка: страница каталога → функция плагина → SQL-запрос → измеренная задержка.

Это основа для технического заключения.

Как доказать, что тормозит именно SQL-запрос

Query Monitor помогает найти проблему. Для подтверждения причины нужны дополнительные измерения.

Шаг 4. Сравните время SQL и время ответа сервера

Проверьте несколько показателей:

Показатель	Что он показывает
TTFB	Время до получения первого байта ответа
Общее время PHP	Сколько выполнялся серверный код
Время SQL	Сколько заняли запросы к базе
Время внешних API	Сколько код ждал другие сервисы
Количество SQL-запросов	Насколько интенсивно код обращается к базе

Допустим, TTFB составляет 2,4 секунды. PHP выполняется 2,3 секунды, а SQL занимает 1,8 секунды. Это указывает на значительный вклад базы данных.

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

Шаг 5. Включите журнал медленных запросов MySQL

Если Query Monitor не даёт полного ответа, изучите серверную базу данных.

В MySQL и совместимых конфигурациях MariaDB можно использовать журнал медленных запросов. Он записывает запросы, которые превышают установленный порог.

Пример настроек MySQL:

[mysqld]
slow_query_log = ON
long_query_time = 1
slow_query_log_file = /var/log/mysql/slow-queries.log

Порог long_query_time = 1 означает одну секунду. Для диагностики можно выбрать меньший порог, если нагрузка и объём логов это позволяют.

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

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

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

Шаг 6. Проверьте план выполнения через EXPLAIN

Журнал показывает, какой запрос выполняется медленно. Команда EXPLAIN помогает понять, почему это происходит.

Например, приложение выполняет такой запрос:

SELECT ID, post_title
FROM wp_posts
WHERE post_type = 'product'
  AND post_status = 'publish'
ORDER BY post_date DESC
LIMIT 50;

Это условный пример. Реальные таблицы и поля зависят от структуры сайта и установленных расширений.

Проверьте план выполнения:

EXPLAIN
SELECT ID, post_title
FROM wp_posts
WHERE post_type = 'product'
  AND post_status = 'publish'
ORDER BY post_date DESC
LIMIT 50;

В результате обратите внимание на следующие поля:

• type — способ доступа к таблице.
• key — выбранный индекс.
• rows — приблизительное число проверяемых строк.
• Extra — дополнительные операции, например сортировка.

Большое значение rows может указывать на лишнее чтение данных. key = NULL означает, что оптимизатор не выбрал индекс для соответствующего доступа.

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

Для запросов с JOIN, сортировкой и фильтрацией изучайте весь план. В поддерживаемых версиях MySQL также используйте EXPLAIN ANALYZE на тестовом окружении. Эта команда действительно выполняет запрос, поэтому запускайте её осторожно.

Шаг 7. Проверьте индексы перед изменением схемы

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

Посмотрите существующие индексы:

SHOW INDEX FROM wp_posts;

Не добавляйте индекс только потому, что увидели type = ALL. Сначала оцените объём таблицы, селективность условий и частоту выполнения запроса.

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

Перед изменением схемы сделайте резервную копию. Проверьте новую конфигурацию на копии базы данных.

Как отличить медленный SQL от проблем PHP и плагинов

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

Проверьте внешние HTTP-запросы

Плагин может обращаться к CRM, службе доставки или платёжному шлюзу. Если внешний сервис отвечает медленно, WordPress будет ждать.

Query Monitor помогает найти такие обращения. Сравните их длительность со временем ответа страницы.

Проверьте повторные обращения к базе

Допустим, плагин загружает товары и отдельно запрашивает метаданные для каждого товара. При выводе 100 позиций число запросов может резко вырасти.

Это разновидность проблемы N+1. Решение зависит от кода: иногда помогает пакетная загрузка данных, иногда — кеширование или изменение структуры запроса.

Проверьте влияние кеша

Сравните первый и повторный запрос. Учитывайте, что кеш страницы, объектный кеш и кеш запросов решают разные задачи.

Проверяйте авторизованные и неавторизованные сценарии отдельно. Корзина и личный кабинет могут обходить кеш страницы по техническим причинам.

Не отключайте кеш на рабочем сайте без необходимости. Сначала проведите тест на копии или настройте контролируемое сравнение.

Практический кейс: каталог WooCommerce открывается слишком долго

Представим типичную ситуацию. Интернет-магазин содержит несколько десятков тысяч товаров. Каталог отвечает за 3,2 секунды, а покупатели жалуются на медленные фильтры.

Команда предполагает, что серверу не хватает оперативной памяти. Но сначала специалисты измеряют нагрузку.

Что показывает диагностика

Query Monitor обнаруживает несколько повторяющихся запросов плагина фильтрации. Журнал MySQL подтверждает задержки при определённых комбинациях фильтров. План выполнения показывает чтение большого числа строк.

Команда проверяет существующие индексы и логику формирования SQL. Затем специалисты тестируют исправление на копии магазина.

Возможные действия:

• уменьшить число повторных обращений;
• изменить запрос, если это безопасно;
• добавить подходящий индекс после проверки плана;
• сократить объём обрабатываемых данных;
• настроить объектный кеш для подходящих результатов.

После изменения команда повторяет тот же сценарий. Специалисты сравнивают медианное время ответа и количество запросов.

Например, время ответа может снизиться с 3,2 до 1,4 секунды. Это иллюстративные цифры, а не результат реального проекта студии «Компьюти».

Главный принцип прост: сравнивайте одинаковые условия до и после исправления. Тогда вы сможете отделить эффект оптимизации от случайных колебаний нагрузки.

Чек-лист: как найти медленный запрос в WordPress

Перед передачей задачи разработчику соберите следующие данные.

• Укажите конкретную медленную страницу и сценарий.
• Зафиксируйте время ответа до изменений.
• Проверьте SQL-запросы через Query Monitor.
• Найдите компонент и вызывающую функцию.
• Сравните время SQL с общим временем PHP.
• При необходимости включите журнал медленных запросов.
• Изучите план выполнения через EXPLAIN.
• Проверьте существующие индексы.
• Подготовьте тестовое исправление.
• Повторите измерения в одинаковых условиях.
• Проверьте ошибки и корректность работы сайта.
• Задокументируйте результат.

Когда стоит обратиться в веб-студию

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

Обратитесь к специалистам, если:

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

В студии «Компьюти» можно начать с аудита производительности WordPress. Специалисты изучат запросы, PHP-код, кеширование и конфигурацию сервера. Затем подготовят план исправлений с приоритетами и контрольными измерениями.

Такой подход помогает избежать бессистемного отключения плагинов и неоправданного увеличения ресурсов сервера.

Заключение

Чтобы найти медленный запрос в WordPress, начните с Query Monitor. Затем подтвердите проблему журналом MySQL и планом EXPLAIN. Сопоставьте результаты с общим временем ответа страницы и проверьте эффект исправлений повторными измерениями.

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

Нужна помощь с диагностикой? Обратитесь в студию «Компьюти». Мы поможем определить узкое место, обосновать решение и проверить результат оптимизации.