«Я хотела “ускорить базу данных”, но боялась, что сайт перестанет работать: рассказываю, как почистила базу без риска и заметно снизила нагрузку»

У меня был сайт онлайн‑школы по маркетингу: WordPress + LearnDash, 85 уроков, личный кабинет ученика, прогресс‑бар, тесты, формы заявок, интеграция с платёжной системой и CRM. Клиент сказал: «Сайт тормозит в личном кабинете, особенно когда ученики сдают тесты. Сделай базу легче, но так, чтобы прогресс, оценки и заказы не пропали». Я кивнула, а внутри всё сжалось: «А если я удалю не то — ученик зайдёт, а его прогресс исчезнет? Или корзина начнёт выдавать ошибки? Или сайт упадёт с 500‑й ошибкой, потому что я “оптимизировала” критичную таблицу?»

До этого я либо вообще не трогала базу (думала: «Работает — не лезь»), либо запускала «волшебные» плагины, которые одним кликом удаляли всё подряд, включая ревизии, комментарии, метаданные — и потом выяснялось, что пропали важные данные или сломались интеграции. Ещё пугала сама мысль о SQL‑запросах: одна опечатка — и можно потерять всю базу. Тогда я поняла: чистка базы — это не «удалить всё лишнее», а точечная работа с пониманием, что именно «раздувает» базу и какие данные критичны. Панель Timeweb с phpMyAdmin, логами и бэкапами дала мне безопасную среду для аккуратной оптимизации.

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

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

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

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

Шаг 1: сделать бэкап базы и зафиксировать текущее состояние

В панели Timeweb я:

Нажала «Создать резервную копию» для базы данных и файлов. Статус «Готов» — теперь я могла откатиться за 10–15 минут.
Зафиксировала текущие метрики: размер базы (в МБ), среднюю нагрузку CPU, время отклика страницы личного кабинета.
Проверила, что ключевые сценарии работают: вход в личный кабинет, открытие урока, отправка теста, оформление заказа.

Это была моя «точка отсчёта»: если после оптимизации что‑то сломается, я точно знала, что откатываюсь на стабильную версию.

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

Я пошла по двум путям:

Способ А (через плагин Database Cleaner / WP‑Optimize): запустила анализ и получила список самых тяжёлых таблиц и типов данных: ревизии постов, спам‑комментарии, черновики, неиспользуемые метаданные плагинов.

Способ Б (через phpMyAdmin в панели Timeweb): посмотрела размеры таблиц вручную. Чаще всего «раздутыми» оказывались:

wp_posts — из‑за ревизий;
wp_postmeta — из‑за старых метаданных удалённых плагинов;
wp_comments — из‑за спама.

Плюс я посмотрела, сколько места занимают старые логи и временные данные (если такие есть в таблицах плагинов). Это дало мне чёткое понимание: не нужно «чистить всё», достаточно убрать 3–4 категории, которые дают 80 % веса.

Шаг 3: точечно удалить лишнее, не трогая критичные данные

Я удаляла только то, что точно не влияет на конверсии и данные учеников:

Ревизии постов. Оставила последние 2–3 версии для важных статей, остальное удалила. В плагине есть настройка «хранить последние N ревизий», я её включила.
Спам‑комментарии и комментарии в корзине. Они не нужны, не влияют на SEO и занимают место.
Черновики и старые автосохранения. Если черновик старше 6 месяцев и не публиковался — удаляла.
Неиспользуемые метаданные. Например, старые настройки удалённых плагинов, которые тянут вес таблицы wp_postmeta.

Что я НЕ трогала:

Метаданные LearnDash (прогресс, оценки, статусы уроков) — они хранятся в wp_postmeta, но имеют чёткие префиксы ключей, которые я исключила из чистки.
Таблицы WooCommerce (заказы, статусы, платежи) — никаких массовых удалений.
Настройки тем и плагинов — они тоже в wp_postmeta, но критичны для работы сайта.

Если нужно было сделать точечную чистку через SQL, я сначала запускала SELECT с лимитом, проверяла, какие строки попадут под удаление, и только потом делала DELETE. Пример безопасного запроса (только для ревизий):

Важно: все SQL‑операции я делала сначала на тестовой копии, а не на основном сайте.

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

После удаления лишнего я:

Запустила OPTIMIZE для основных таблиц в phpMyAdmin: wp_posts, wp_postmeta, wp_comments. Это убирает «дыры» в данных, которые остаются после удалений, и реально снижает размер базы.
Проверила целостность таблиц. В phpMyAdmin есть кнопка «Проверить» — она показывает, нет ли битых индексов или ошибок структуры.
Переиндексировала, если нужно. Если таблица большая и часто меняется, перестройка индексов ускоряет выборки.

Результат: размер базы уменьшался на 30–50 %, а нагрузка на CPU падала заметно.

Шаг 5: протестировать ключевые сценарии и убедиться, что ничего не сломалось

На обновлённой базе я прошла по чек‑листу:

Личный кабинет ученика. Прогресс, список уроков, статусы тестов — всё должно быть на месте.
Корзина и оформление заказа. Проверка, что заказы создаются, статусы обновляются, CRM получает данные.
Тесты и отправка результатов. Убедиться, что оценки сохраняются, а прогресс пересчитывается корректно.
Консоль браузера (F12 → Console). Не должно быть ошибок, связанных с базой или AJAX‑запросами.
Логи сервера (error.log в панели Timeweb). Если есть ошибки подключения к БД или таймауты — сразу видно.

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

Шаг 6: настроить регулярную лёгкую чистку и контроль

Чтобы база снова не «раздулась», я:

Включила автоматическую чистку в плагине с безопасными настройками: хранить последние ревизии, удалять спам, чистить черновики старше 30 дней.
Настроила мониторинг размера базы и нагрузки в панели хостинга: если размер резко растёт или CPU подскакивает — это сигнал проверить, не появился ли спам или не сломался ли какой‑то плагин.
Раз в месяц делала ручной аудит через phpMyAdmin: смотрела, какие таблицы самые тяжёлые, и при необходимости делала точечную чистку.
Держала бэкапы актуальными и раз в месяц тестировала восстановление на тестовом поддомене.

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

Хотела удалить все ревизии сразу. Думала: «Они не нужны». Поддержка подсказала: «Оставьте последние 2–3 версии для важных страниц, иначе при ошибке вы не сможете быстро вернуть контент».
Пыталась чистить wp_postmeta целиком. Думала: «Там много мусора». Но именно в этой таблице хранятся прогресс учеников и настройки плагинов. Панель и практика подсказали: чистить только по префиксам или через плагин с исключениями.
Игнорировала OPTIMIZE после удалений. Думала: «Удалила строки — база стала легче». Но без OPTIMIZE место не освобождается, а индексы становятся неэффективными.
Не проверяла целостность таблиц. Думала: «Если сайт открывается, значит, всё ок». В phpMyAdmin панель показала битые индексы, которые сильно тормозили выборки.
Не тестировала на копии. Думала: «Запрос простой, ничего не случится». На тесте я увидела, что один из запросов случайно удалял метаданные прогресса — и это спасло основной сайт от потери данных.

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

Бэкапы базы в один клик. Я могла откатиться за минуты и не бояться, что «оптимизация» сломает сайт.
phpMyAdmin с удобным интерфейсом. Быстро смотрела размеры таблиц, запускала SELECT/DELETE/OPTIMIZE, проверяла целостность.
Доступ к логам (error.log, access.log). Если после оптимизации появлялись ошибки БД или таймауты, я сразу видела причину.
Поддомены для тестов. Я разворачивала копию сайта и базы на test-school.site.ru и делала всю чистку там, прежде чем переносить на основной сайт.
Панель с метриками нагрузки. Видно, как меняется CPU и время отклика после оптимизации — это лучший индикатор реального эффекта.
Поддержка. Когда сомневалась, можно ли удалять определённые типы метаданных или как правильно написать SQL‑запрос, в чате быстро подсказывали безопасный вариант.

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

Если вы тоже планируете оптимизировать базу WordPress:

Всегда делайте бэкап перед любой чисткой. На Timeweb это пара кликов, а откатиться можно за минуты.
Сначала тестируйте на копии сайта. Любые SQL‑запросы и массовые удаления — только на тестовой базе.
Не удаляйте данные наугад. Сначала посмотрите, какие таблицы самые тяжёлые и что в них хранится.
Исключайте критичные данные. Прогресс учеников, заказы, статусы платежей — эти данные нельзя чистить массово.
Используйте SELECT перед DELETE. Сначала посмотрите, какие строки будут удалены, и только потом запускайте удаление.
После удалений запускайте OPTIMIZE. Это реально уменьшает размер базы и ускоряет работу.
Проверяйте целостность таблиц. Если есть битые индексы — исправьте их, иначе оптимизация не даст эффекта.
Тестируйте ключевые сценарии. Пока корзина, личный кабинет и тесты не работают идеально — работу нельзя считать завершённой.
Настройте регулярную лёгкую автоматическую чистку. Но с безопасными исключениями и лимитами.
Держите реестр критических таблиц и ключей. Какие данные нельзя трогать ни при каких условиях — это экономит часы при разборе инцидентов.

Сейчас я спокойно оптимизирую базы: знаю, что у меня есть бэкап, тестовая площадка, phpMyAdmin для точечной работы, контроль логов и чёткий план действий. А клиент получает более быстрый сайт и стабильный личный кабинет: нагрузка на базу падает, страницы открываются быстрее, а данные учеников и заказы остаются в безопасности. И всё это благодаря тому, что я перестала бояться SQL и начала действовать системно. А Timeweb даёт для этого все нужные инструменты: бэкапы, phpMyAdmin, логи, поддомены и поддержку, которая помогает не потерять данные в погоне за скоростью.