Если WordPress начал тормозить, а в логах и на хостинге нет очевидной ошибки, часто проблема сидит не в «самом WordPress», а в одном или нескольких медленных SQL-запросах. Они могут выполняться на каждой странице, раздувать время ответа сервера и создавать ощущение, что сайт «тяжелый» даже при небольшом трафике.
Чтобы найти такую причину, нужно не гадать, а сначала увидеть, какие запросы выполняются долго, откуда они приходят и почему база данных выбирает неудачный путь. В WordPress это обычно делается через профилирование запросов, логи медленных запросов MySQL/MariaDB и проверку конкретных плагинов, темы и собственных запросов в коде.
С чего начать, если сайт просто стал медленным
Сначала убедитесь, что проблема действительно связана с запросами к базе данных, а не с внешними факторами. Если медленно открываются все страницы, включая простые записи без тяжелых блоков, это уже похоже на проблему на уровне сервера, БД или плагина, который делает много запросов.
Проверьте три вещи:
- медленно ли открывается весь сайт или только отдельные страницы;
- замедление есть в админке, на фронтенде или в обоих местах;
- меняется ли скорость после отключения кэша, тяжелых плагинов или смены темы на стандартную.
Если страница долго формируется, а потом уже быстро отдается браузеру, почти всегда стоит смотреть на PHP и SQL. Если же сервер отвечает быстро, но долго грузятся изображения, скрипты или шрифты, это уже другая задача.
Как найти тяжелые запросы в WordPress
Самый практичный путь — смотреть не на абстрактную «нагрузку», а на конкретные запросы, время их выполнения и источник. Для этого есть несколько рабочих способов, и лучше использовать их вместе.
Плагин для отладки запросов
Для локальной проверки или на staging-сайте удобно использовать Query Monitor. Он показывает SQL-запросы, время выполнения, количество повторов, вызовы PHP, HTTP-запросы и многое другое. Это не инструмент для постоянной работы на боевом сайте под высокой нагрузкой, но для диагностики он очень полезен.
После установки откройте проблемную страницу и посмотрите:
- какие запросы выполняются дольше остальных;
- есть ли одинаковые запросы, повторяющиеся десятки раз;
- какой плагин, тема или участок кода их инициирует;
- есть ли запросы без индексов или с большим числом строк в результате.
Если один и тот же запрос повторяется много раз, проблема может быть не в самом SQL, а в логике кода: например, цикл делает запрос на каждой итерации вместо одного выборочного запроса.
Лог медленных запросов MySQL или MariaDB
Если есть доступ к настройкам базы данных на хостинге, включите slow query log. Это уже уровень сервера, и он показывает запросы, которые реально выполняются дольше заданного порога. Такой лог особенно полезен, когда сайт тормозит не постоянно, а только под нагрузкой или на отдельных страницах.
Обычно в лог попадают запросы, которые долго читают большие таблицы, делают сортировку без индекса или используют слишком широкий поиск. Но включать лог нужно аккуратно: на активном сайте он может быстро разрастись. Если хостинг позволяет, задайте разумный порог, например 1–2 секунды, и включайте лог на ограниченное время для диагностики.
Если вы не управляете сервером напрямую, запросите у хостинга выгрузку slow log или помощь в его включении. Это нормальная практика для shared-хостинга и управляемых VPS.
Профилирование на уровне кода
Если у вас есть доступ к теме или плагину, ищите не только сам SQL, но и место, где он вызывается. В WordPress медленные запросы часто появляются из-за:
- неудачного использования
WP_Queryс лишними параметрами; - запросов к метаполям через
wp_postmetaбез индексов; - частых обращений к
optionsилиtransientsв цикле; - получения слишком большого объема данных вместо нужных нескольких строк;
- собственных запросов через
$wpdbбез подготовки и без учета индексов.
Если запрос написан в плагине, сначала проверьте, есть ли у него настройки кэширования или ограничения объема данных. Если запрос в вашей теме, его часто можно упростить без изменения внешнего результата.
Как понять, что именно тормозит запрос
Когда медленный запрос найден, важно не ограничиваться временем выполнения. Нужно понять, почему он медленный. В MySQL это обычно связано с планом выполнения, отсутствием индекса, большим количеством строк или неудачным условием поиска.
Для анализа полезно посмотреть EXPLAIN для проблемного запроса. Он показывает, как сервер собирается его выполнять: использует ли индекс, сколько строк просматривает, есть ли сортировка по временной таблице. Это уже более технический шаг, но без него часто невозможно понять, почему запрос «вроде простой», а работает плохо.
Типичные признаки проблемного запроса:
- поиск по полю, которое не индексировано и содержит много записей;
- сравнение по
LIKE '%слово%', из-за которого индекс обычно не помогает; - сортировка по вычисляемому полю или по нескольким полям без подходящего индекса;
- запрос к таблице
wp_postmetaс большим объемом данных; - слишком широкий выбор данных, когда нужен один пост, а выбираются сотни строк.
Если вы не уверены в чтении плана выполнения, начните с более простого: сравните время запроса до и после отключения подозрительного плагина или после временного упрощения условия. Это часто быстрее, чем сразу разбирать весь SQL-план.
Что обычно замедляет WordPress на практике
В реальных проектах тяжелые запросы чаще всего появляются не из-за ядра WordPress, а из-за того, как сайт использует данные.
Перегруженные метаполя
Таблица wp_postmeta — частый источник проблем. Она удобна, но плохо подходит для сложной фильтрации на больших объемах данных. Если сайт хранит много произвольных полей и активно по ним ищет, сортирует или фильтрует записи, запросы быстро становятся дорогими.
Особенно это заметно на каталогах, фильтрах, страницах с большим количеством кастомных полей и в админке, где список записей строится по нескольким метаусловиям.
Слишком много запросов в одном шаблоне
Иногда проблема не в одном тяжелом запросе, а в сотнях мелких. Например, шаблон выводит список записей, а внутри цикла для каждого элемента делает отдельный запрос за автором, рейтингом, счетчиком просмотров или дополнительным полем. На маленьком сайте это незаметно, но на реальном трафике начинает сильно тормозить.
Здесь помогает проверка количества запросов на странице. Если их слишком много, ищите возможность собрать данные заранее, использовать кэш или убрать повторяющиеся обращения.
Плагины, которые делают запросы на каждом хите
Некоторые плагины выполняют запросы при каждом открытии страницы: статистика, фильтры, связанные записи, рейтинги, сложные формы, интеграции. Если плагин написан неаккуратно, он может нагружать БД даже тогда, когда его блок не виден пользователю.
Практический способ проверки простой: отключите подозрительный плагин на staging-копии и сравните время генерации страницы и число запросов. Если разница заметна, источник найден.
Как исправить медленные запросы без риска сломать сайт
Не все оптимизации одинаково безопасны. Если вы не уверены в структуре базы, сначала делайте копию сайта и базы данных. Любые изменения индексов, SQL-запросов и кода лучше проверять на тестовой копии, а не на живом проекте.
Рабочие способы исправления обычно такие:
- убрать лишние запросы из шаблона или плагина;
- ограничить объем выбираемых данных;
- добавить кэширование результата там, где данные меняются редко;
- переписать запрос так, чтобы он использовал индекс;
- перенести тяжелую выборку в фоновые задачи или предварительную подготовку данных.
Если запрос строится через WP_Query, проверьте, действительно ли нужны все параметры. Иногда достаточно отключить лишние поля, не считать общее количество записей или убрать ненужные сортировки. Если запрос написан вручную через $wpdb, убедитесь, что он не тянет всю таблицу ради нескольких строк.
Кэширование помогает, когда результат запроса меняется редко. Например, список популярных записей, агрегаты, настройки или справочные данные можно сохранить в transient или объектный кэш. Но если данные обновляются постоянно, кэш нужно продумать, иначе вы получите устаревший вывод.
Когда имеет смысл менять структуру данных
Если сайт вырос и постоянно упирается в одни и те же тяжелые запросы, точечная оптимизация уже не спасает. В таком случае проблема может быть в самой модели данных. Для WordPress это типичная история: сначала удобно хранить всё в постах и метаполях, а потом фильтры, сортировки и отчеты начинают тормозить.
Признаки, что пора менять подход:
- один и тот же запрос регулярно попадает в slow log;
- оптимизация дает небольшой эффект и быстро заканчивается;
- данные растут, а время ответа тоже растет;
- запросы завязаны на сложные метаполя и множественные JOIN.
В таких случаях иногда лучше вынести часть данных в отдельную таблицу с нормальными индексами или пересмотреть логику хранения. Это уже разработческая задача, но она часто дает более стабильный результат, чем бесконечная «докрутка» одного и того же запроса.
Как проверить, что проблема действительно решена
После исправления не ориентируйтесь только на субъективное ощущение «стало быстрее». Сравните конкретные показатели:
- время генерации страницы до и после;
- количество SQL-запросов;
- наличие проблемного запроса в Query Monitor или slow log;
- поведение сайта под повторной нагрузкой.
Если запрос исчез из slow log, а страница стала формироваться заметно быстрее, значит вы нашли правильную причину. Если же сайт ускорился только на одной странице, а в других местах тормоза остались, ищите следующий узкий участок. В WordPress медлительность часто складывается из нескольких небольших проблем, а не из одной большой.
Самый надежный порядок работы такой: сначала зафиксировать симптом, потом найти конкретный запрос, затем понять, кто его вызывает, и только после этого менять код или структуру данных. Такой подход экономит время и снижает риск сломать рабочий сайт ради сомнительной оптимизации.