Оптимизация БД WordPress: уменьшил базу с 180MB до 90MB

Полгода назад я заметил, что админка WordPress стала тормозить. Не критично, но противно: нажал «Сохранить» — ждёшь 2-3 секунды. Я начал грешить на хостинг, на PHP, на плагины. А оказалось, проблема была в базе данных.

Зашёл в phpMyAdmin и офигел. Таблица wp_options весила 45 мегабайт. Там хранились транзиты за полгода. Тысячи записей от плагинов, которые уже удалены. Ещё wp_postmeta — 120 тысяч строк с метаданными.

Чистка

Поставил плагин WP-Optimize. Он чистит транзиты, спам-комментарии, ревизии, метаданные. Первый прогон очистил 400 мегабайт. Реально.

Потом выполнил OPTIMIZE TABLE всех таблиц. Размер БД уменьшился с 180MB до 90MB. Админка стала летать.

Ещё настроил автоматическую очистку транзитов раз в неделю через cron. Теперь БД не разрастается. 10 минут работы — и сайт как новый.

Что ещё

Включил persistent object cache через Redis. WordPress делает меньше запросов к БД. На CPU нагрузка снизилась в 2 раза.

В итоге: админка грузится за 0.8с вместо 3с, БД 90MB вместо 180MB. Если сайт тормозит — начните с базы данных.

Больше статей про WordPress — от установки до продвижения — я собрал в сводном гайде.

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

Всё началось с того, что админка WordPress стала заметно тормозить. Не критично, но противно: нажимаешь «Сохранить» — и ждёшь две-три секунды. Иногда страницы списков постов открывались медленно. Я, как многие, начал грешить на хостинг, на PHP, на плагины. Перебирал плагины, отключал подозрительные, даже думал про апгрейд сервера. А проблема оказалась не в этом — она была в базе данных, которая годами копила мусор.

Когда я наконец зашёл в phpMyAdmin и посмотрел на таблицы, я офигел. Таблица wp_options весила 45 мегабайт! Там хранились транзиты — временные данные, которые плагины записывают «на время», — за полгода. Тысячи записей от плагинов, которые давно удалены. Плюс таблица wp_postmeta — 120 тысяч строк с метаданными, половина из которых была бесполезной. Всё это лежало в базе, раздувало её и замедляло каждый запрос. И главное — я ничего об этом не знал, потому что никогда не смотрел на базу.

Теперь разберу, откуда берётся этот мусор, чтобы ты понимал механизм. Транзиты — это кэш, который плагины записывают в базу на короткое время. Проблема в том, что «короткое время» часто истекает, а записи остаются лежать, пока их кто-то не почистит. Ревизии записей — это копии постов при каждом сохранении; если ты много редактируешь статьи, их накапливается огромное количество. Спам-комментарии, которые не удалены, тоже висят годами. Плюс метаданные от удалённых плагинов. Всё это — мёртвый груз.

Решение нашлось быстро — плагин WP-Optimize. Он умеет чистить транзиты, спам-комментарии, ревизии, мусорные метаданные — всё то, что я перечислил выше. Первый прогон был шокирующим: плагин очистил 400 мегабайт мусора. Четыреста мегабайт! Я даже не подозревал, что столько всего накопилось. После этого я выполнил OPTIMIZE TABLE для всех таблиц — эта команда дефрагментирует таблицы и приводит их в порядок. Итог: база данных уменьшилась с 180 мегабайт до 90. Вдвое. Просто удалив мусор.

Про то, как это повлияло на производительность, расскажу с цифрами. Админка, которая грузилась за три секунды, стала открываться за 0.8 секунды. Страницы постов в админке — мгновенно. Сайт в целом стал отзывчивее, потому что каждый запрос к базе стал легче. Я был поражён, насколько сильно раздутая база влияла на всё. Ощущение было такое, будто я снял с рюкзака груз, который нёс незаметно. И всё это — за десять минут работы.

Но самое главное — это не разовая чистка, а предотвращение. Я настроил автоматическую очистку транзитов раз в неделю через cron. Теперь база не разрастается снова. Это ключевой момент: если почистить раз и забыть, через полгода база снова раздуется. А регулярная очистка держит её в форме постоянно. Включил расписание — и забыл о проблеме навсегда. Пять минут на настройку, а эффект — постоянный.

Что ещё я сделал в рамках этой оптимизации — включил постоянный объектный кеш через Redis. Звучит сложно, но на деле это просто: Redis — это хранилище ключ-значение в памяти, и WordPress может использовать его для кеширования результатов запросов. Вместо того чтобы каждый раз лезть в базу, WordPress берёт данные из быстрой памяти. Нагрузка на CPU у меня снизилась вдвое. Если у тебя есть возможность поставить Redis — очень рекомендую. Это следующий шаг после чистки базы.

Почему это важно в комплексе? Чистая база + объектный кеш = вдвое меньше работы для сервера. База отвечает быстрее, потому что она маленькая и дефрагментированная. WordPress реже обращается к ней, потому что кеш отдаёт готовые ответы из памяти. Вместе это даёт ощутимый прирост, который замечают и пользователи (сайт быстрее), и вы (меньше нагрузки на сервер). Эти две вещи работают в связке и усиливают друг друга.

Теперь о том, как часто стоит это делать. Мой график такой: автоматическая чистка транзитов — раз в неделю. Глубокая чистка с удалением ревизий и мусорных метаданных — раз в месяц. OPTIMIZE TABLE — раз в месяц, после глубокой чистки. Проверка размера базы — раз в месяц, чтобы видеть динамику. Это занимает минимум времени, а база всегда в форме. Если ты ведёшь активный блог с комментариями и правками — интервалы могут быть короче.

Ещё один важный момент — не удаляй всё подряд. WP-Optimize даёт настройки, и не стоит включать все галочки разом. Например, не удаляй ревизии, которые тебе могут понадобиться для отката, если активно редактируешь статьи. Я оставил разумные лимиты: хранить последние несколько ревизий, чистить только то, что точно мусор. Лучше быть осторожным, чем случайно удалить нужные данные. Сначала посмотри, что именно плагин собирается удалить.

Про выбор инструмента скажу пару слов. Я использовал WP-Optimize, но есть и другие хорошие решения: Optimize Database after Deleting Revisions, WP-Sweep и так далее. Не обязательно выбирать именно WP-Optimize — посмотри, что удобнее. Главное — чтобы плагин умел чистить транзиты, ревизии, спам и метаданные, и чтобы он был актуальным и совместимым с твоей версией WordPress. Любой такой инструмент решит задачу.

Что бы я посоветовал новичку, который подозревает, что его сайт тормозит из-за базы. Первое — зайди в phpMyAdmin и посмотри размер таблиц. Если wp_options больше 20 мегабайт или wp_postmeta содержит сотни тысяч строк — база переполнена мусором. Второе — поставь плагин оптимизации и прогони чистку. Третье — выполни OPTIMIZE TABLE. Четвёртое — настрой регулярную очистку. Пятое — измерь результат. Десять минут — и ты увидишь, насколько это просто.

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

Подведу итог. Оптимизация базы данных — это простой, быстрый и очень эффективный способ ускорить WordPress. Чистка мусора, дефрагментация таблиц, регулярная очистка и объектный кеш дали мне двукратное уменьшение базы и многократное ускорение админки. Если твой сайт тормозит — начни с базы данных. Это может быть та самая причина, о которой ты даже не подозреваешь. Десять минут работы — и сайт как новый. Не откладывай — проверь свою базу сегодня.

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

Второе — про таблицу wp_options. Это одна из самых важных таблиц, и её раздувание — частая проблема. Там хранятся настройки, и многие плагины пишут туда свои данные без ограничений. После удаления плагина его записи часто остаются. Мой совет: при удалении плагина используй деинсталляцию, которая чистит данные, а если плагин давно удалён — собери мусор вручную через чистку wp_options. Освободившееся место может удивить.

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

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

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

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