Как уменьшить нагрузку на базу данных WordPress

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

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

С чего начать: что именно нагружает базу WordPress

В WordPress нагрузку обычно создают не «большие» записи, а большое количество мелких и часто бесполезных строк. Чаще всего это:

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

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

Очистка ревизий и автосохранений

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

Самый безопасный подход — сначала проверить, сколько ревизий накопилось, и только потом чистить. Если у вас есть доступ к базе через phpMyAdmin или другой SQL-клиент, можно посмотреть количество ревизий так:

SELECT COUNT(*) AS revisions_count FROM wp_posts WHERE post_type = 'revision';

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

DELETE FROM wp_posts WHERE post_type = 'revision';

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

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

Удаление временных данных и просроченных транзиентов

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

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

Через WP-CLI это делается командой:

wp transient delete --expired

Команда удаляет только просроченные транзиенты. Если WP-CLI на хостинге недоступен, можно использовать плагин для обслуживания базы или сделать очистку через админку, если такой инструмент есть в вашем наборе. Вручную лезть в таблицы wp_options и удалять всё подряд не стоит: там хранятся и важные настройки сайта.

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

Что ещё можно безопасно убрать

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

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

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

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

Как уменьшить будущий рост базы, а не только почистить старую

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

Для ревизий можно ограничить их количество в wp-config.php. Это особенно полезно на сайтах, где записи часто редактируют несколько авторов. Добавьте строку до комментария /* That's all, stop editing! Happy publishing. */:

define('WP_POST_REVISIONS', 5);

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

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

Как проверить, что нагрузка действительно снизилась

После очистки не стоит ориентироваться только на ощущение, что «админка стала быстрее». Лучше проверить несколько вещей:

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

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

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

Когда лучше использовать плагин, а когда чистить вручную

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

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

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

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