«Я думала, что “очистить базу данных и ускорить сайт” — это страшно и долго, а потом за вечер убрала 40 % “мусора” и снизила нагрузку: рассказываю, как безопасно почистила базу WordPress на Timeweb»

У меня был сайт агентства недвижимости: WordPress, много статей про районы, карточки объектов, формы заявок, плюс год активной работы с рассылками и комментариями. Клиент сказал: «Сайт стал тормозить, особенно в админке. Надо что‑то делать». Я открыла phpMyAdmin в панели Timeweb, увидела, что база весит 1,8 ГБ — и меня накрыла паника: «А вдруг я удалю не то, и пропадут все карточки объектов? Или сломаю формы? Или после чистки сайт вообще не откроется?»

До этого я боялась трогать базу: казалось, что это «святая святых», где любая правка — гарантированный крах. Но тормоза в админке (открытие страницы тянулось по 15–20 секунд) мешали работать, а клиент ждал результатов. Тогда я поняла: надо чистить, но строго по шагам, с бэкапами и без «удалить всё подряд».

Чего я боялась больше всего

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

Удалить важные данные. Боялась, что очищу «лишние» таблицы и исчезнут товары, страницы или настройки плагинов.
Сломать сайт из‑за сериализованных данных. Слышала, что если неправильно менять строки в базе, CMS перестанет читать настройки.
Не суметь откатиться. Если что‑то пойдёт не так, я не смогу быстро вернуть базу в исходное состояние.
Сделать только хуже. Что чистка не ускорит сайт, а я потрачу время и создам риск для проекта.
Потерять историю заявок. В базе хранились старые лиды и статусы CRM‑интеграций, и я не хотела их случайно затереть.

С этим списком я пошла в панель Timeweb и составила план: сначала бэкап, потом точечная чистка, потом замеры скорости.

Шаг 1: сделать бэкап базы и всего сайта

Первое, что я сделала, — ручной бэкап в панели Timeweb. Нажала «Создать резервную копию», выбрала «Сайт + База данных», подождала пару минут. Статус «Готов» дал ощущение страховки: если что‑то сломается, я верну всё назад за 5 минут.

Это реально сняло половину стресса: теперь я знала, что даже если случайно удалю таблицу, откачусь без потерь.

Шаг 2: понять, что именно раздувает базу

Я открыла phpMyAdmin в панели хостинга и посмотрела список таблиц, отсортировав по размеру. Сразу бросились в глаза:

wp_posts — огромная, но в ней были не только статьи, а ещё и ревизии.
wp_comments — много спама и старых комментариев.
Несколько таблиц от старых плагинов, которые я удалила полгода назад, но их таблицы остались.

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

Шаг 3: почистить ревизии постов

Ревизии — это копии статей при каждом сохранении. Они полезны, но если их тысячи, база становится тяжёлой. Я выбрала безопасный способ: не вручную удалять строки, а через SQL‑запрос, который удаляет только ревизии, не трогая сами посты.

В phpMyAdmin я открыла вкладку «SQL» и вставила:

Нажала «Вперёд» — и через пару секунд ревизии исчезли. База сразу уменьшилась примерно на 600 МБ.

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

Шаг 4: убрать спам‑комментарии и старые ответы

В таблице wp_comments накопилось больше 12 000 строк, из них около 9 000 — спам и «спасибо» без смысла. Удалять вручную было нереально, поэтому я использовала SQL:

И отдельно удалила очень старые комментарии, которые не нужны для аналитики:

Перед этим я выгрузила комментарии в CSV, чтобы при необходимости можно было проверить, что ничего важного не удалено.

Шаг 5: удалить остатки старых плагинов

Я вспомнила, что полгода назад отключала и удаляла несколько плагинов (конструктор форм, старый SEO‑плагин), но их таблицы в базе остались. В phpMyAdmin я посмотрела список таблиц и нашла префиксы, которые не используются в текущей установке.

Осторожно удалила только эти таблицы — не через DROP DATABASE, а точечно, по одной. Это освободило ещё около 200 МБ и убрало «шум», который мог мешать оптимизации.

Шаг 6: оптимизировать таблицы и проверить скорость

После чистки я сделала «Оптимизировать таблицу» для всех оставшихся таблиц в phpMyAdmin. Это убирает «дыры» в данных и делает базу компактнее.

Затем я:

Зашла в админку WordPress и открыла пару тяжёлых страниц — они стали открываться за 3–4 секунды вместо 15–20.
Проверила размер базы — было 1,8 ГБ, стало около 1,05 ГБ.
Посмотрела нагрузку в панели хостинга — CPU и память стали ниже, сайт меньше «напрягался».

Для клиента это было заметно сразу: админка перестала «висеть», редактирование карточек объектов стало быстрым.

Шаг 7: настроить регулярную профилактику

Чтобы база не распухала снова, я сделала два простых правила:

Ограничить ревизии. Установила плагин, который хранит не больше 3 ревизий на пост.
Автоочистка спама. Настроила плагин комментариев так, чтобы спам удалялся через 7 дней автоматически.

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

Где я чуть не ошиблась (и что панель подсказала)

Хотела удалить таблицы вручную, кликая «Удалить». Хорошо, что остановилась: можно случайно стереть важную таблицу. Я использовала SQL с чёткими условиями, а не удаляла «на глаз».
Пыталась править сериализованные данные в базе. Думала: «Сейчас заменю домен в базе через простой поиск‑замену». Поддержка подсказала: для миграции и замены URL используйте специальные плагины, иначе сломаются настройки.
Забыла сделать бэкап перед SQL‑запросами. В первый раз я начала с тестовой базы, но хотела сразу на основной. Панель и здравый смысл сказали: сначала бэкап.
Думала, что «оптимизация таблиц» — это лишнее. Оказалось, что после удаления тысяч строк таблицы остаются «раздутыми», и оптимизация реально уменьшает размер и ускоряет работу.

Что реально помогло на Timeweb

Бэкапы в один клик. Я могла откатиться за минуты, если SQL‑запросы что‑то сломали.
phpMyAdmin прямо в панели. Не нужно ставить сторонние клиенты: всё доступно в браузере.
Файловый менеджер и доступ к логам. Если сайт начинал выдавать ошибки, я быстро смотрела логи и понимала, в чём проблема.
Поддержка. Когда сомневалась, можно ли удалять старые таблицы плагинов, в чате быстро подсказали, какие таблицы точно не нужны.
Статистика базы и нагрузка CPU. Панель показывает, сколько места занимает база и как сильно нагружен сервер, — это помогает понять, есть ли эффект от чистки.

Практические советы, чтобы безопасно чистить базу и ускорить сайт

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

Всегда делайте бэкап перед любыми изменениями в базе. На Timeweb это пара кликов, а откатиться можно за минуты.
Сначала тестируйте SQL‑запросы на тестовой базе. Так вы увидите, что именно удалится, и не сломаете основной сайт.
Чистите ревизии через правильный SQL. Не удаляйте строки наугад — используйте проверенные запросы.
Удаляйте только остатки старых плагинов. Если плагин не используется и его таблицы не нужны — удаляйте, но только точечно.
Оптимизируйте таблицы после массовой чистки. Это убирает «пустоты» и делает базу компактнее.
Настройте лимиты ревизий и автоочистку спама. Так база не будет быстро расти снова.
Следите за размером базы и нагрузкой. Если база снова начнёт расти, вы вовремя заметите проблему.
Не меняйте сериализованные данные вручную. Для замены URL и миграций используйте специальные плагины.

Сейчас база держится на уровне 1–1,2 ГБ, админка работает быстро, сайт не тормозит даже при пиковой нагрузке. Я перестала бояться слова «база данных»: поняла, что это не «чёрный ящик», а обычный инструмент, который можно безопасно чистить и оптимизировать. А Timeweb даёт всё необходимое: бэкапы, phpMyAdmin, статистику, понятную панель и поддержку, которая помогает не наломать дров.