Ускорение Битрикс: партиционирование таблиц MySQL

Партиционирование таблиц MySQL для 1С-Битрикс — это техника настройки MySQL, которая решает проблему разрастания таблицы b_stat_hit до 50 миллионов строк, когда DELETE старых записей блокирует таблицу на минуты, а SELECT по диапазону дат идёт через полный скан. Это типичная картина для проектов без партиционирования. Наши инженеры с 10+ летним опытом, сертификацией Битрикс и более 50 успешными проектами гарантируют корректное внедрение без простоев. Партиционирование — разделение таблицы MySQL на физические секции. Запросы обращаются только к нужной секции, удаление старых данных — мгновенное DROP PARTITION вместо тяжёлого DELETE. В одном проекте с 80 миллионами хитов статистики время удаления данных за месяц сократилось с 12 минут до 0.1 секунды — это в 7200 раз быстрее. На другом проекте с каталогом из 500 000 товаров и посещаемостью 100 000 хостов в сутки таблица b_stat_hit росла на 3 миллиона строк в день — после партиционирования проблема блокировок исчезла.

Партиционирование не панацея, но для больших таблиц с временным измерением оно даёт прирост производительности в 10–50 раз на операциях выборки и очистки. Мы используем RANGE-партиционирование по дате — самый прозрачный и обслуживаемый вариант для Битрикс. Ниже разберём, какие таблицы нужно партиционировать в первую очередь и как это реализовать без простоев.

Какие таблицы Битрикс стоит партиционировать?

Не все таблицы выигрывают от партиционирования. Кандидаты — большие таблицы с временным измерением:

Таблицы статистики — первый кандидат: данные старше 3 месяцев редко нужны, а DELETE FROM b_stat_hit WHERE DATE_HIT < NOW() - INTERVAL 3 MONTH на 30 миллионах строк — это 10 минут блокировки. После партиционирования удаление занимает миллисекунды.

Почему это важно для производительности Битрикс?

Без партиционирования MySQL сканирует всю таблицу, даже если нужны данные за последнюю неделю. С партициями оптимизатор выполняет partition pruning — отбрасывает секции, не подходящие под условие WHERE. Это снижает нагрузку на I/O и CPU в десятки раз. Например, SELECT с фильтром по дате на партиционированной таблице выполняется в 30–50 раз быстрее. Для наглядности — сравнение операций:

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

Как автоматизировать ротацию партиций?

После настройки партиций нужно обеспечить их регулярное добавление и удаление. Используем cron-скрипт на Bash, который вызывается ежемесячно. Пример логики:

#!/bin/bash MONTH=$(date +%Y-%m) PART_NAME="p_$MONTH" SQL="ALTER TABLE b_stat_hit REORGANIZE PARTITION p_future INTO (PARTITION $PART_NAME VALUES LESS THAN (TO_DAYS('$(date +%Y-%m-%d -d '+1 month'))'), PARTITION p_future VALUES LESS THAN MAXVALUE);" mysql -u user -p db -e "$SQL" # Удаление старой партиции, например, старше 6 месяцев OLD_PART=$(date +%Y-%m -d '-6 months') OLD_SQL="ALTER TABLE b_stat_hit DROP PARTITION p_$OLD_PART;" mysql -u user -p db -e "$OLD_SQL" 

Скрипт должен быть запущен с правами на изменение таблиц. Мы настраиваем его на сервере и тестируем автоматическую ротацию.

Как реализуем партиционирование: пошагово

1. Анализируем таблицы-кандидаты: размер, характер запросов, скорость роста.
2. Изменяем первичные ключи, если требуется (добавляем столбец даты).
3. Создаём RANGE-партиции по дате. Пример для b_stat_hit:

ALTER TABLE b_stat_hit PARTITION BY RANGE (TO_DAYS(DATE_HIT)) ( PARTITION p_jan VALUES LESS THAN (TO_DAYS('2099-02-01')), PARTITION p_feb VALUES LESS THAN (TO_DAYS('2099-03-01')), PARTITION p_mar VALUES LESS THAN (TO_DAYS('2099-04-01')), PARTITION p_future VALUES LESS THAN MAXVALUE ); 

Документация MySQL Partitioning требует, чтобы столбец партиционирования входил в каждый уникальный индекс и первичный ключ. Для b_stat_hit первичный ключ — ID. Приводим его к составному:

ALTER TABLE b_stat_hit DROP PRIMARY KEY, ADD PRIMARY KEY (ID, DATE_HIT); ALTER TABLE b_stat_hit PARTITION BY RANGE (TO_DAYS(DATE_HIT)) (...); 

Проверяем, что Битрикс не использует ID для JOIN — если использует, составной PK безопасен.

4. Настраиваем cron-скрипт для ротации партиций:

   • Создание новой партиции: REORGANIZE PARTITION p_future INTO (PARTITION p_apr VALUES LESS THAN (TO_DAYS('2099-05-01')), PARTITION p_future VALUES LESS THAN MAXVALUE).
   • Удаление старой: ALTER TABLE b_stat_hit DROP PARTITION p_old.

   Тестируем производительность: замеряем время SELECT и DELETE до и после. Обычно улучшение в 10–50 раз, а удаление данных — в тысячи раз быстрее.

   Что входит в нашу работу

   • Анализ базы данных и выявление таблиц-кандидатов.
   • Изменение первичных ключей без потери данных.
   • Создание RANGE-партиций по дате.
   • Разработка и настройка cron-скрипта для автоматической ротации.
   • Проверка совместимости с обновлениями ядра Битрикс.
   • Документирование всех изменений.
   • Поддержка после внедрения (1 месяц).

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

   Ограничения в контексте Битрикс

   • Обновления ядра. Модуль main при обновлении может выполнить ALTER TABLE — если структура изменилась, а партиции не учтены, обновление может сломаться. Мы ведём список партиционированных таблиц и проверяем перед каждым обновлением.
   • ORM D7. Bitrix\Main\ORM не знает о партициях — запросы работают прозрачно, но оптимизатор MySQL выполнит partition pruning только если в WHERE есть условие по столбцу партиционирования.
   • InnoDB ограничения. Максимум 8192 партиции на таблицу (MySQL 8). Для месячного партиционирования — это более 680 лет.

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