База данных сайта разрослась, админка тормозит

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

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

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

Что вообще лежит в базе данных

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

Содержание сайта. Товары, страницы, статьи, разделы, характеристики, изображения (точнее, ссылки на них), настройки.

Заказы и заявки. Вся история обращений с момента запуска.

Пользователи. Учётные записи покупателей, если есть личный кабинет.

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

Статистика. Некоторые системы управления ведут собственный учёт посещений внутри базы.

Сессии посетителей. Временные записи о каждом визите. Их создаётся очень много.

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

Черновики и версии. История правок страниц и товаров.

Корзины. Незавершённые заказы посетителей, включая тех, кто зашёл и ушёл.

Очереди задач. Записи о запланированных операциях: отправка писем, обмены, выгрузки.

Первые три пункта — это ценность. Остальные — служебная нагрузка, которая при отсутствии обслуживания растёт бесконечно.

Почему база растёт быстрее, чем кажется

Несколько типичных источников разрастания.

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

Журналы действий. Каждое изменение в администраторской части фиксируется. При активной работе с каталогом это десятки тысяч записей в год.

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

Черновики и версии страниц. Некоторые системы сохраняют каждое промежуточное состояние. Страница, которую правили пятьдесят раз, хранится пятьдесят раз.

Незавершённые заказы. Брошенные корзины копятся годами.

Записи о срабатывании защиты от спама. Каждая попытка спам-отправки фиксируется. При активной атаке это тысячи записей в сутки.

Кеш, который не очищается. Устаревшие фрагменты остаются лежать.

Данные удалённых объектов. Многие системы не удаляют записи физически, а только помечают как удалённые. Товар исчез из каталога, но его характеристики, изображения и связи остались в базе.

Как понять, что дело именно в базе

Признаки довольно характерные.

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

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

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

Хостинг присылает уведомления о превышении лимитов по нагрузке или по объёму базы.

Резервное копирование стало занимать много времени, а файл копии вырос до нескольких гигабайт при небольшом каталоге.

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

Что можно чистить безопасно

Начнём с того, что удаляется практически без риска.

Сессии старше нескольких дней. Никакой ценности не представляют. Записи о визитах, завершившихся месяц назад, не нужны никому.

Кеш. Пересоздастся автоматически. Единственное последствие очистки — сайт первые минуты будет работать чуть медленнее, пока кеш наполняется заново.

Записи о попытках спама старше нескольких месяцев. Если вы не расследуете конкретную атаку, они бесполезны.

Служебные журналы старше года. Здесь стоит подумать: иногда история изменений нужна, чтобы понять, кто и когда что-то сломал. Разумный подход — хранить год, старше выгружать в файл и удалять из базы.

Брошенные корзины старше полугода. Если вы не делаете рассылки по незавершённым заказам, они не нужны. Если делаете — храните три месяца, дальше смысла нет.

Промежуточные версии страниц. Оставьте последние несколько, остальные удалите.

Данные модулей, которые вы больше не используете. При удалении модуля его таблицы часто остаются. Перед удалением обязательно убедитесь, что модуль действительно не работает.

Записи об очередях выполненных задач.

Что нужно архивировать, а не удалять

Есть данные, которые из базы убрать полезно, но потерять нельзя.

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

Старые заявки с форм. То же самое. Особенно если поток большой.

История обменов с 1С. Может быть нужна для разбора конкретных ситуаций, но не должна жить в базе годами.

Данные о клиентах, которые давно не покупали. Здесь нужна осторожность: прежде чем что-то трогать, убедитесь, что эти записи не используются в отчётах и не связаны с активными заказами.

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

Что трогать нельзя

Отдельный список — на случай, если чистку кто-то решит делать самостоятельно.

Таблицы с настройками системы. Их структура и содержание критичны, и восстановить их из головы невозможно.

Связи между объектами. Удаление записей о связях товаров с разделами, характеристиками или изображениями превращает каталог в набор разрозненных данных.

Записи, помеченные как удалённые, но связанные с заказами. Товар может быть снят с продажи, но если он присутствует в старых заказах, физическое удаление приведёт к тому, что заказы станут нечитаемыми.

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

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

Оптимизация без удаления

Иногда удалять ничего не нужно, а помогает техническое обслуживание.

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

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

Пересборка кеша. Некоторые системы позволяют перестроить кеш целиком — это помогает, когда он разросся и стал неэффективным.

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

Что делать регулярно

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

Раз в неделю — автоматическая очистка сессий и устаревшего кеша. Настраивается один раз задачей по расписанию.

Раз в месяц — очистка записей о спаме, старых корзин, промежуточных версий страниц.

Раз в квартал — архивирование заказов и заявок старше установленного срока, оптимизация таблиц.

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

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

Как это связано с продвижением 3 в 1

Может показаться, что обслуживание базы — тема чисто техническая и к обращениям отношения не имеет. Связь есть, и прямая.

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

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

Отдельно про нейропоиск: генеративные системы тоже обращаются к сайту, и медленный ответ или таймаут означает, что данные не получены. В ответ на вопрос пользователя попадёт тот, кто ответил быстро.

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

2ГИС. Аудитория 2ГИС в основном звонит прямо из приложения, и на неё скорость сайта влияет меньше. Это ещё один довод в пользу того, чтобы держать карточки заполненными: когда сайт по каким-то причинам работает плохо, карточки продолжают приносить обращения.

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

Короткая памятка

Тормозит администраторская часть сильнее публичной — почти наверняка дело в базе.

Посмотрите размер базы и размеры отдельных таблиц.

Сделайте и проверьте резервную копию.

Почистите очевидный мусор: сессии, кеш, записи о спаме, старые корзины, лишние версии страниц.

Заархивируйте старые заказы и заявки вместо удаления.

Оптимизируйте таблицы после чистки.

Проверьте индексы по часто используемым полям — это работа для специалиста, но эффект самый заметный.

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

Не трогайте таблицы, назначение которых не понимаете.

Вывод

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

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

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