Почему WordPress раздувает базу?
WordPress может работать годами и постепенно накапливать в базе тысячи и даже десятки тысяч записей, которые владелец сайта никогда не видит.
В админке всё выглядит нормально.
Страниц — несколько десятков.
Записей — сотня.
Плагинов — немного.
А база при этом занимает уже сотни мегабайт или больше.
Откуда взялся весь этот объём?
Причина обычно не в самих страницах.
WordPress хранит гораздо больше информации, чем видит пользователь.
Настройки плагинов, ревизии записей, временные данные, метаинформация, остатки удалённых расширений, служебные записи и различные кэши постепенно накапливаются внутри MySQL/MariaDB.
И самое неприятное — часть этого мусора продолжает участвовать в работе сайта.
💬 Большая база сама по себе ещё не означает проблему. Проблема начинается тогда, когда сайт постоянно работает с данными, которые ему уже не нужны.
Разберём, что именно раздувает базу WordPress и почему удалять всё подряд — плохая идея.
Большая база ≠ медленный сайт
Это первое, что нужно понять.
Если база WordPress занимает 500 МБ, это ещё не означает, что сайт обязательно будет медленным.
И наоборот.
Небольшая база может содержать несколько тяжёлых или неправильно настроенных параметров, которые будут создавать заметную нагрузку при каждом запросе.
Поэтому смотреть только на размер базы недостаточно.
Нужно понимать:
🔹 какие таблицы занимают больше всего места;
🔹 какие данные постоянно запрашиваются;
🔹 сколько записей находится в wp_options;
🔹 сколько данных загружается автоматически;
🔹 сколько старых записей оставили плагины;
🔹 сколько ревизий накопилось;
🔹 есть ли огромное количество мета-записей;
🔹 работают ли временные данные и кэш корректно.
Особое внимание стоит уделять таблице wp_options.
Именно там часто находится одна из самых неприятных причин деградации WordPress — чрезмерный объём autoloaded options.
Что такое autoload в WordPress
WordPress хранит настройки в базе данных.
Плагины и темы тоже активно используют эту систему.
Условно можно представить ситуацию так:
Плагин устанавливается → создаёт настройки → сохраняет их в wp_options → часть настроек помечает для автоматической загрузки.
И здесь возникает проблема.
Autoload означает, что определённые параметры WordPress загружает автоматически при обработке запроса.
То есть данные могут быть нужны только одному плагину или одной странице админки, но при неправильной настройке они начинают загружаться гораздо шире.
Официальная документация WordPress отдельно предупреждает, что слишком большое количество autoloaded options может ухудшать производительность. В документации WordPress в качестве ориентира для совокупного объёма autoloaded options указывается значение около 800 КБ и ниже.
И вот здесь начинается интересная часть.
Проблема может появиться не из-за количества строк.
Несколько крупных записей способны быть опаснее тысяч маленьких.
Например, условный плагин может сохранить в одной option сериализованный массив с огромным количеством данных.
Визуально это одна строка.
Для базы — одна запись.
Но внутри неё может находиться большой объём информации.
Почему wp_options часто становится проблемной
На небольшом сайте wp_options обычно не вызывает никаких вопросов.
Но со временем туда начинают писать:
🔹 WordPress;
🔹 тема;
🔹 конструктор страниц;
🔹 SEO-плагины;
🔹 формы;
🔹 системы аналитики;
🔹 WooCommerce;
🔹 кэш-плагины;
🔹 интеграции с внешними сервисами;
🔹 различные служебные расширения.
Каждый компонент добавляет свои параметры.
Само по себе это нормально.
Проблема появляется, когда плагин удалён, а его данные остаются.
Или когда разработчик сохраняет слишком большой объём информации с autoload.
Или когда временные данные используются неправильно.
В итоге сайт продолжает загружать то, что ему уже не требуется.
WordPress постепенно превращается в систему, где каждый новый плагин оставляет после себя ещё один слой данных.
Ревизии: скрытый архив WordPress
Одна из самых понятных причин роста базы — ревизии.
Вы открываете запись.
Меняете заголовок.
Исправляете абзац.
Меняете изображение.
Нажимаете «Обновить».
Через некоторое время снова редактируете текст.
WordPress может сохранять предыдущие состояния записи.
Это удобно.
Если вы случайно удалили важный кусок текста, можно вернуть старую версию.
Но у этой функции есть обратная сторона.
Если на сайте:
🔹 500 записей;
🔹 активно ведётся блог;
🔹 редакторы постоянно правят материалы;
🔹 используются конструкторы страниц;
🔹 автоматически сохраняются изменения;
то количество исторических версий способно вырасти очень сильно.
Особенно быстро это становится заметно на крупных проектах.
WordPress официально предусматривает возможность ограничивать количество сохраняемых ревизий. В документации по оптимизации базы также рекомендуется контролировать количество ревизий, если они создают лишний объём.
Но здесь есть важный нюанс.
Ревизии нельзя просто удалить вслепую.
Сначала нужно понять, действительно ли они больше не нужны.
На рабочем корпоративном сайте одна ситуация.
На сайте, где редакторы ежедневно работают с большими материалами, — другая.
Транзиенты: временные данные, которые не всегда временные
Ещё один источник роста базы — Transients API.
WordPress использует транзиенты для хранения временных данных.
Например:
плагину нужно сохранить результат какого-то запроса на определённое время.
Вместо того чтобы каждый раз обращаться к внешнему API или выполнять тяжёлую операцию, результат можно сохранить и использовать повторно.
Это нормальный механизм.
Более того, он специально предусмотрен WordPress.
Но проблема возникает при неправильном использовании.
Если постоянного объектного кэша вроде Redis или Memcached нет, транзиенты могут храниться в базе данных, обычно в wp_options.
И вот тут появляется интересная особенность.
Транзиент с корректным временем жизни отличается от данных, которые фактически никогда не истекают.
WordPress отдельно предупреждает: транзиенты без срока действия могут попадать в autoload и загружаться при каждом запросе.
Представьте 1000 подобных записей.
Каждая кажется мелочью.
Но вместе они превращаются в заметный объём.
Плагин удалили, а данные остались
Это один из самых распространённых сценариев.
Владелец сайта устанавливает плагин.
Использует его несколько месяцев.
Потом решает:
«Этот плагин больше не нужен».
Нажимает «Деактивировать».
Потом удаляет.
Визуально всё чисто.
Но база может помнить этот плагин ещё очень долго.
Почему?
Потому что деактивация и удаление файлов не всегда означает полное удаление данных из базы.
Некоторые разработчики предусматривают очистку настроек при удалении плагина.
Некоторые — нет.
Другие оставляют данные намеренно, чтобы после повторной установки пользователь не потерял настройки.
В результате спустя несколько лет база может содержать настройки десятков уже несуществующих расширений.
И особенно неприятно то, что эти данные не всегда легко узнать по названию.
Можно увидеть что-то вроде:
plugin_option_123
или
some_cache_data
или
custom_settings
и не понимать, имеет ли это отношение к действующему функционалу.
Вот почему ручное удаление случайных строк из базы — плохой способ оптимизации.
Мета-данные могут расти быстрее самого сайта
WordPress хранит не только сами записи.
У каждой записи могут быть дополнительные данные.
Например:
🔹 значения пользовательских полей;
🔹 параметры SEO;
🔹 настройки изображения;
🔹 данные WooCommerce;
🔹 значения конструктора страниц;
🔹 технические параметры плагинов;
🔹 произвольные поля.
Для этого используются отдельные таблицы, например wp_postmeta.
И здесь количество записей способно очень быстро увеличиваться.
Допустим, на сайте 10 000 товаров.
Если каждый товар получает десятки дополнительных параметров, количество строк в wp_postmeta может стать значительно больше количества самих товаров.
Само по себе это не ошибка.
WordPress именно так и работает.
Но плохо спроектированный плагин может создавать большое количество ненужных мета-записей.
Ещё хуже, когда данные дублируются.
Например, обновление одного объекта создаёт новую запись вместо корректного изменения старой.
Через несколько лет такой механизм способен превратить таблицу в огромный архив.
Конструкторы страниц тоже оставляют след
Современный WordPress часто работает не только с обычным редактором.
На сайте могут использоваться визуальные конструкторы.
Они сохраняют гораздо больше информации о странице:
🔹 структуру блоков;
🔹 настройки элементов;
🔹 стили;
🔹 параметры адаптивности;
🔹 анимации;
🔹 дополнительные атрибуты;
🔹 служебные значения.
Поэтому одна визуально простая страница для человека может представлять собой довольно сложный набор данных для WordPress.
А теперь представьте сайт, который несколько раз полностью переделывали.
Старые блоки заменили.
Дизайн изменили.
Конструктор обновлялся.
Плагины менялись.
Часть элементов удалялась.
Но часть старых данных могла остаться.
Получается интересная ситуация:
страница выглядит новой, а база хранит историю предыдущих решений.
WooCommerce способен увеличить базу в разы
На обычном корпоративном сайте рост базы часто происходит постепенно.
В интернет-магазине всё сложнее.
Потому что кроме страниц и записей появляются:
🔹 товары;
🔹 вариации;
🔹 заказы;
🔹 данные покупателей;
🔹 статусы;
🔹 метаинформация;
🔹 купоны;
🔹 настройки доставки;
🔹 платежные данные;
🔹 служебные записи.
Если магазин активно работает несколько лет, база закономерно становится большой.
И здесь размер уже нельзя оценивать по принципу:
«Удалим старые данные — станет быстрее».
Некоторые старые заказы являются частью бизнес-истории.
Их нельзя просто удалить ради уменьшения размера базы.
Для интернет-магазина задача заключается не в том, чтобы сделать базу как можно меньше.
Задача — убрать действительно ненужные данные и правильно организовать работу с теми, которые нужны бизнесу.
Что происходит после нескольких лет работы
Вот типичный сценарий.
Первый год
Сайт устанавливается.
Плагинов немного.
База маленькая.
Проблем нет.
Второй год
Появляется новый функционал.
Добавляются интеграции.
Меняется тема.
Устанавливаются новые плагины.
Появляются дополнительные записи и ревизии.
Всё ещё нормально.
Третий год
Сайт несколько раз дорабатывался.
Часть плагинов удалили.
Некоторые заменили другими.
Были редизайны.
Появились новые формы.
Добавилась аналитика.
База постепенно растёт.
Четвёртый-пятый год
Владелец замечает странности.
Админка стала открываться дольше.
Резервная копия стала значительно тяжелее.
Импорт занимает больше времени.
Некоторые операции выполняются с задержкой.
При этом главная страница может по-прежнему открываться быстро.
И возникает вопрос:
«Почему сайт вроде бы быстрый, но WordPress внутри становится всё тяжелее?»
Очень часто ответ находится именно в базе.
Как понять, что база требует проверки
Не обязательно ждать, пока сайт начнёт падать.
Есть несколько признаков, которые должны насторожить.
⚠️ Размер базы непропорционален объёму сайта.
⚠️ Резервные копии базы становятся неожиданно большими.
⚠️ Админка работает заметно медленнее публичной части сайта.
⚠️ Некоторые операции в WordPress выполняются с задержкой.
⚠️ После удаления плагинов база почти не уменьшается.
⚠️ В wp_options обнаруживаются очень крупные записи.
⚠️ В базе много старых технических данных.
⚠️ После нескольких лет работы сайт ни разу не проходил техническую очистку.
Это ещё не означает, что база обязательно неисправна.
Но это хороший повод провести диагностику.
Как правильно проверять базу WordPress
Первое правило:
не начинать с кнопки «Очистить».
Сначала нужно понять структуру данных.
Шаг 1. Сделать резервную копию
Перед любой операцией с базой должна существовать рабочая резервная копия.
Причём не просто архив файлов.
Нужна копия самой базы.
Если что-то пойдёт не так, восстановить сайт из одного wp-content может оказаться недостаточно.
Шаг 2. Посмотреть размер таблиц
Нужно определить, какие таблицы действительно занимают место.
Например:
wp_posts
wp_postmeta
wp_options
wp_comments
wp_commentmeta
и другие таблицы, созданные плагинами.
Если неожиданно огромной оказывается таблица, которую должен использовать небольшой плагин, это уже повод искать причину.
Шаг 3. Проверить wp_options
Здесь особенно интересно посмотреть:
🔹 размер отдельных options;
🔹 значение autoload;
🔹 старые настройки плагинов;
🔹 транзиенты;
🔹 большие сериализованные массивы;
🔹 данные от давно удалённых расширений.
Современный WordPress позволяет управлять autoload более гибко. Начиная с изменений в Options API, WordPress может учитывать размер значения при определении автозагрузки, а для больших значений предусмотрена логика, препятствующая автоматической загрузке без явного указания разработчика.
Но это не означает, что старую базу можно оставить без проверки.
На сайте, который много лет переносился между версиями WordPress и плагинами, может находиться исторический слой настроек.
Почему нельзя удалять всё подозрительное
Самая опасная ошибка — открыть phpMyAdmin и начать удалять записи, которые выглядят ненужными.
Например:
«Этот option принадлежит старому плагину. Удаляем».
А потом оказывается, что другой компонент всё ещё использует эту настройку.
Или:
«Это огромный transient. Удаляем».
А он был частью рабочего механизма интеграции.
Или:
«Все ревизии не нужны».
А через неделю редактору требуется восстановить старую версию важной статьи.
База WordPress — это не склад файлов, где можно просто выбросить всё старое.
Каждая запись имеет контекст.
Поэтому сначала нужно определить владельца данных.
Кто их создал?
Какой плагин?
Используются ли они сейчас?
Что произойдёт после удаления?
Можно ли восстановить их автоматически?
Только после этого принимается решение.
Очистка базы — не соревнование по мегабайтам
Представим два сайта.
Первый:
база — 150 МБ;
autoload — небольшой;
таблицы структурированы;
старого мусора мало;
запросы работают нормально.
Второй:
база — 70 МБ;
огромный wp_options;
много ненужных autoloaded options;
старые данные от плагинов;
неоптимальные запросы.
Какой сайт лучше?
Очевидно, второй вызывает больше вопросов.
Поэтому цель оптимизации — не получить минимальную цифру возле надписи «Размер базы».
Цель — сделать так, чтобы база содержала необходимые данные и не заставляла WordPress постоянно обрабатывать лишнее.
Что обычно можно оптимизировать
После диагностики можно рассматривать несколько направлений.
Ревизии
Удалить действительно ненужные старые версии и установить разумные ограничения для будущего.
Транзиенты
Проверить временные данные и убедиться, что они используются корректно.
WordPress прямо предусматривает автоматическое истечение транзиентов и возможность их удаления, когда они больше не нужны.
Старые options
Найти настройки от давно удалённых компонентов.
Но удалять их только после подтверждения.
Autoload
Проверить крупные параметры, которые загружаются автоматически.
Это один из наиболее интересных участков диагностики, потому что здесь проблема может влиять не только на размер базы, но и на обработку запросов.
Мета-данные
Посмотреть, какие плагины создают большое количество postmeta, usermeta и других связанных записей.
Дубликаты
Проверить, не создаёт ли какой-либо компонент повторяющиеся данные.
Таблицы сторонних плагинов
Если плагин удалён, его таблицы могут остаться.
Но перед удалением необходимо убедиться, что они действительно больше никем не используются.
Оптимизация таблиц — отдельная задача
Есть ещё одна вещь, которую часто путают с очисткой.
Очистить данные и оптимизировать таблицы — не одно и то же.
Можно удалить ненужные записи.
Но после массовых изменений структура таблицы может требовать дополнительного обслуживания.
В WordPress для работы с базой существуют штатные инструменты и WP-CLI-команды, включая wp db optimize, которая запускает оптимизацию таблиц через mysqlcheck.
Однако и здесь не стоит превращать оптимизацию в автоматическую процедуру:
«Запустим optimize — вдруг станет быстрее».
Сначала должна быть причина.
Потом действие.
Потом проверка результата.
Как не допустить повторного разрастания базы
Очистить базу один раз недостаточно.
Если причина осталась, через год ситуация повторится.
Поэтому нужно смотреть не только назад, но и вперёд.
Контролируйте количество плагинов
Чем больше расширений работает на сайте, тем больше компонентов потенциально записывает свои данные.
Это не означает:
«Чем меньше плагинов, тем лучше».
Плохой один плагин может создать больше проблем, чем десять нормально разработанных.
Вопрос в качестве и назначении каждого компонента.
Не устанавливайте плагины «на всякий случай»
Если функциональность не нужна — не нужно добавлять её в WordPress.
Каждый новый компонент увеличивает техническую сложность проекта.
Проверяйте последствия удаления
После удаления крупного плагина полезно понимать, что произошло с его данными.
Особенно если он работал годами.
Следите за autoload
На больших проектах это должно быть частью технического аудита.
Не только:
«Сколько весит база?»
Но и:
«Сколько данных WordPress загружает автоматически?»
Это гораздо более полезный вопрос.
Особенно опасны старые сайты после нескольких редизайнов
Есть сайты, которые никогда не создавались заново.
Их просто постоянно дорабатывали.
2019 год — одна тема.
2021 — новый конструктор.
2023 — новые плагины.
2024 — редизайн.
2025 — интеграция CRM.
2026 — ещё один набор доработок.
Посетитель видит один сайт.
WordPress может видеть историю всех этих изменений.
В базе остаются следы старых решений.
Именно поэтому иногда после технического аудита оказывается, что проблема не в текущей конфигурации сайта.
Проблема — в наследии предыдущих разработок.
Почему увеличение хостинга не всегда помогает
Представим ситуацию.
Сайт стал работать тяжелее.
Владелец переходит на более дорогой тариф.
Процессор мощнее.
Оперативной памяти больше.
Сайт действительно может стать немного быстрее.
Но если WordPress продолжает загружать огромный объём ненужных данных, причина никуда не исчезает.
Это похоже на автомобиль с забитым воздушным фильтром.
Можно поставить двигатель мощнее.
Но сначала стоит разобраться с самим ограничением.
С базой происходит то же самое.
Серверные ресурсы не заменяют нормальную структуру данных.
Что происходит после правильной оптимизации
Хорошая работа с базой не обязательно даёт эффект:
«Было 500 МБ — стало 50 МБ».
Иногда размер меняется незначительно.
Но при этом:
🔹 уменьшается объём autoloaded options;
🔹 исчезают старые служебные данные;
🔹 сокращается количество ненужных запросов;
🔹 быстрее выполняются отдельные операции;
🔹 уменьшается нагрузка на MySQL;
🔹 резервные копии становятся компактнее;
🔹 админка работает стабильнее;
🔹 становится проще диагностировать будущие проблемы.
Именно поэтому оценивать результат только по размеру базы неправильно.
База должна расти — но управляемо
Важно не впасть в другую крайность.
WordPress-сайт не должен иметь минимальную базу любой ценой.
Если компания публикует статьи, база будет расти.
Если интернет-магазин получает заказы, база будет расти.
Если появляются новые товары, пользователи и документы — данные будут добавляться.
Это нормально.
Рост базы — естественная часть жизни сайта.
Проблема начинается тогда, когда база растёт быстрее, чем сам проект, за счёт технического мусора.
Если сайт получил 500 новых товаров — увеличение базы логично.
Если сайт практически не менялся, но wp_options внезапно выросла в несколько раз — уже нужно искать причину.
Как выглядит нормальная диагностика
Профессиональная проверка базы начинается не с очистки.
Она начинается с вопросов.
🔹 Какие таблицы самые большие?
🔹 Что именно хранится внутри?
🔹 Какие плагины их создают?
🔹 Какие данные используются сейчас?
🔹 Что является временным?
🔹 Какие options загружаются автоматически?
🔹 Есть ли старые данные удалённых плагинов?
🔹 Сколько ревизий хранится?
🔹 Есть ли избыточные метаданные?
🔹 Что изменится после очистки?
И только после ответов можно выбирать инструмент.
Иногда достаточно удалить старые ревизии.
Иногда нужно разобрать wp_options.
Иногда проблема находится в конкретном плагине.
А иногда база полностью нормальна, и искать причину медленной работы нужно вообще в другом месте.
Самая опасная ошибка — чистить базу без диагностики
Парадоксально, но желание ускорить сайт может привести к его поломке.
Особенно если владелец находит инструкцию:
«Удалите эти 15 типов записей — и WordPress станет быстрее».
На тестовом сайте это может сработать.
На рабочем проекте — нет гарантии.
У каждого сайта своя история.
Один использует WooCommerce.
Другой — сложную CRM-интеграцию.
Третий — конструктор.
Четвёртый — собственные плагины.
Пятый вообще содержит нестандартную структуру данных.
Поэтому универсальная SQL-команда для «очистки WordPress» — вещь, к которой стоит относиться очень осторожно.
Что стоит проверить владельцу сайта
Если WordPress работает несколько лет и база ни разу не проверялась, можно начать с простого.
📌 Узнать размер базы.
📌 Посмотреть самые большие таблицы.
📌 Проверить wp_options.
📌 Посмотреть объём autoloaded options.
📌 Проверить количество ревизий.
📌 Найти старые плагины и их данные.
📌 Проверить транзиенты.
📌 Посмотреть рост базы в динамике.
📌 Перед изменениями сделать резервную копию.
И главное — не удалять данные только потому, что они выглядят непонятно.
Непонятная запись не обязательно является мусором.
WordPress не «портит» базу сам
Здесь стоит снять одно распространённое заблуждение.
WordPress не просыпается ночью и не решает:
«Сегодня добавлю ещё 300 МБ мусора».
База растёт потому, что код сайта постоянно записывает туда данные.
WordPress.
Тема.
Плагины.
Интеграции.
Конструкторы.
WooCommerce.
Кастомные разработки.
Автоматические процессы.
Поэтому вопрос правильнее формулировать не так:
«Почему WordPress раздувает базу?»
А так:
«Какой компонент моего сайта создаёт данные, которые больше не нужны или используются неправильно?»
И вот этот вопрос уже приводит к реальной причине.
База — это память сайта
У сайта можно поменять дизайн.
Можно заменить логотип.
Можно ускорить загрузку.
Можно поставить новый сервер.
Но база хранит историю того, как проект развивался.
И чем старше сайт, тем важнее понимать, что именно находится внутри.
Особенно если проект пережил:
🔹 несколько разработчиков;
🔹 несколько редизайнов;
🔹 переносы между хостингами;
🔹 десятки установленных плагинов;
🔹 удаление и замену расширений;
🔹 масштабные изменения функциональности.
В таком случае база становится своеобразным техническим архивом проекта.
Часть этого архива необходима.
Часть — уже нет.
Задача технической оптимизации заключается не в том, чтобы уничтожить архив.
Она заключается в том, чтобы отделить нужные данные от ненужных и перестать заставлять WordPress работать с лишним.
Сначала понять, потом чистить
Большая база WordPress — не приговор.
И сама по себе цифра в мегабайтах ничего не говорит о состоянии сайта.
Гораздо важнее:
🔹 что именно занимает место;
🔹 какие данные загружаются автоматически;
🔹 какие таблицы растут;
🔹 какие плагины создают лишние записи;
🔹 сколько старых данных осталось после предыдущих доработок;
🔹 насколько активно база используется текущей версией сайта.
Иногда после анализа выясняется, что база совершенно нормальная.
Иногда находится один плагин, который годами создавал тысячи ненужных записей.
Иногда основной источник проблемы — огромный wp_options.
А иногда причина вообще не в размере базы, а в конкретных запросах и архитектуре сайта.
Поэтому правильный подход выглядит просто:
Сначала диагностика → затем понимание причины → потом очистка → после этого проверка результата.
Не наоборот.
WordPress способен годами работать стабильно даже на большой базе.
Но если технический мусор начинает расти быстрее, чем сам сайт, откладывать диагностику уже не стоит.
Потому что база — это не просто место, где WordPress хранит данные.
Это фундамент, с которым работает практически весь сайт.