Оптимизация базы WordPress: как не навредить сайту

Удалить старые записи и нажать «оптимизировать таблицы» — не универсальный способ ускорить WordPress. Иногда это почти ничего не меняет, а иногда удаляет данные, на которые рассчитывает плагин. Работайте в таком порядке: сначала найдите медленный запрос, затем проверьте резервную копию и только после этого меняйте базу. Рекомендации относятся к WordPress 6.x; поведение плагинов и команд WP-CLI зависит от их версий.

Сначала выясните, что именно тормозит

Задержка страницы может возникать в PHP, на внешнем API, в сети или в базе. Если измерять только общее время загрузки, легко оптимизировать не тот участок. Сравните время ответа сервера и нагрузку на базу на конкретных страницах: например, в каталоге с фильтрами, поиске или административном списке заказов.

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

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

Четыре подхода и их цена

Порядок работ без неприятных сюрпризов

1. Зафиксируйте исходное состояние. Запишите время ответа проблемной страницы, длительность и частоту медленных запросов, загрузку CPU и объём таблиц. Повторите измерения в сопоставимых условиях. Проверка: у вас есть значения «до», а не впечатление, что сайт «кажется медленным».
2. Сделайте резервную копию файлов и базы. Убедитесь, что архив хранится отдельно от сайта и что копию можно восстановить на тестовом окружении. Проверка: восстановленный сайт открывается, а админка и ключевые сценарии работают.
3. Найдите источник запроса. Сопоставьте медленные запросы с плагином, темой или собственным кодом через профилировщик и журналы базы. Проверка: вы можете указать конкретную страницу и компонент, который создаёт нагрузку.
4. Проверьте кеширование и настройки компонента. Если одни и те же данные читаются повторно, проверьте поддержку постоянного объектного кеша у хостинга и корректность его интеграции с WordPress. Проверка: после прогрева уменьшились повторные обращения к базе, а данные на сайте обновляются после изменения.
5. Удаляйте только известные данные. Сначала выясните, какой компонент создал таблицу или запись и можно ли их удалить штатными средствами самого плагина. На тестовой копии проверьте корзину, поиск, формы, заказы и отчёты. Проверка: нужные сценарии работают, а размер базы и измерения изменились предсказуемо.
6. Проверяйте эффект после каждого изменения. Не удаляйте данные, меняйте настройки кеша и добавляйте индексы одним пакетом. Проверка: повторные замеры показывают улучшение именно проблемного сценария, а ошибки в логах не выросли.

Что обычно чистят зря

Ревизии записей

Ревизии помогают вернуть прежнюю версию страницы. Их количество можно ограничивать настройкой WordPress, но удаление уже накопленных ревизий — отдельная операция. Перед очисткой выясните, нужна ли редакции история изменений и не использует ли её рабочий процесс публикации. Само по себе большое число ревизий ещё не доказывает, что именно они замедляют запросы.

Транзиенты

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

Таблицы плагинов

Отключение плагина не всегда удаляет созданные им таблицы. Но и отсутствие активного плагина не означает, что таблица бесполезна: там могут храниться заказы, статистика, формы или данные для повторной установки. Удаляйте её только после проверки документации и наличия проверенной копии.

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

Когда нужен индекс, а когда — исправление кода

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

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

Что ломается и как откатиться

• После очистки пропали записи или настройки. Восстановите базу из копии и выясните, кто создал удалённые данные. Не повторяйте очистку на боевом сайте, пока не проверили результат на тестовом.
• После включения кеша показываются старые данные. Проверьте, очищается ли кеш при изменении записи, цены или статуса заказа. Для динамических страниц исключите кеширование там, где это требует документация используемого решения.
• База стала медленнее принимать записи. Проверьте, не добавили ли лишние индексы и не запустили ли ресурсоёмкую очистку в часы пик. Изменения структуры таблиц должен оценить специалист, который знает вашу СУБД и нагрузку.
• На тесте всё работает, а на продакшене нет. Сверьте версии WordPress, плагинов, PHP и СУБД, а также объём данных. Различия в окружении могут менять план выполнения и поведение кеша.

Что делать дальше

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

Смежная тема — настройка резервного копирования WordPress: здесь важен только один принцип — до очистки должна существовать проверенная возможность восстановления.

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