Оптимизация базы данных WordPress: чек-лист перед продакшеном

Перед запуском WordPress в продакшен проверьте не только размер базы, но и то, какие запросы тормозят, растут ли таблицы и можно ли восстановиться после неудачной очистки. Этот чек-лист рассчитан на WordPress 6.x и MySQL 8.0 или MariaDB — точную совместимость определяют версии PHP, базы и плагинов на вашем хостинге. Ниже — что проверить до изменений, что можно чистить и как убедиться, что оптимизация не сломала сайт.

Сначала зафиксируйте исходное состояние

Оптимизация без исходных замеров превращается в угадывание. Сначала запишите время ответа страниц и административной панели, нагрузку на сервер, размер базы и объём таблиц. Сравнивайте одинаковые страницы при сопоставимых условиях: без этого нельзя понять, стало быстрее или просто изменился трафик.

До любых изменений подготовьте:

• полную резервную копию базы и файлов сайта;
• проверенную процедуру восстановления, включая доступ к панели хостинга или командной строке;
• копию сайта на staging — тестовом окружении, не доступном обычным посетителям;
• список версий WordPress, PHP, MySQL или MariaDB, активных плагинов и темы;
• базовые показатели: время ответа, частоту ошибок, загрузку процессора и диска.

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

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

Чек-лист перед запуском

1. Проверьте рост таблиц и их назначение

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

Для крупной таблицы выясните:

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

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

2. Разберите автосохранения, ревизии и временные данные

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

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

3. Найдите медленные запросы, а не угадывайте

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

Для каждого кандидата установите, кто его создаёт: ядро, тема или плагин. Затем проверьте, повторяется ли он на чистой теме или после отключения конкретного расширения на staging. Отключать плагины по одному на боевом сайте нельзя: посетители могут потерять функциональность, а магазин — приём заказов.

Если запрос дорогой, сначала ищите настройку или обновление компонента, который его создаёт. Индексы и изменение структуры таблиц требуют понимания схемы: не добавляйте индекс по догадке. Он может ускорить чтение, но увеличить стоимость записи и занять место. После изменения проверьте план запроса средствами вашей версии СУБД и сравните результат на одинаковых данных.

4. Проверьте фоновые задачи и внешние вызовы

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

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

5. Сравните меры по риску и ожидаемому эффекту

Что нельзя считать безопасной оптимизацией

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

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

Как понять, что изменение помогло

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

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

Сноска. Индекс — структура, которую СУБД использует, чтобы быстрее находить строки. Индекс может ускорить чтение, но занимает место и добавляет работу при изменении данных.

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

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