Оптимизация базы данных 1С-Битрикс

Оптимизация базы данных 1С-Битрикс

После нескольких лет эксплуатации Битрикс-сайта база данных накапливает проблемы: разросшиеся таблицы кеша, устаревшие сессии, фрагментированные индексы, неэффективные запросы без индексов. Оптимизация БД — не разовая операция, а регулярный процесс. Разберём конкретные таблицы и методы.

Диагностика: что занимает место

Начинайте с анализа размеров таблиц. В MySQL/MariaDB:

SELECT
    TABLE_NAME,
    ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS size_mb,
    TABLE_ROWS
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'bitrix_db'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC
LIMIT 20;

Для Битрикс-сайтов типично: b_event_log, b_stat_session, b_stat_adv_back, b_search_content, b_cache_tag, b_file — занимают 80% объёма БД.

Таблицы кеша

b_cache_tag — таблица тегов кеша. При каждом сбросе кеша Битрикс не удаляет устаревшие записи немедленно, а помечает их. Таблица растёт постоянно.

Очистка устаревших тегов кеша:

DELETE FROM b_cache_tag WHERE SITE_ID IS NULL AND CACHE_SALT IS NULL;

Либо через административный раздел Настройки → Управление модулями → Главный модуль → Очистить кеш.

Полная пересборка таблицы после очистки:

OPTIMIZE TABLE b_cache_tag;

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

Таблица сессий

b_user_session и b_sale_user_session хранят пользовательские сессии. Без настроенной очистки они растут бесконечно.

Проверить, включена ли автоматическая очистка сессий: Настройки → Настройки продукта → Главный модуль → вкладка «Сессия». Параметр «Время жизни сессии» должен соответствовать session.gc_maxlifetime в php.ini.

Принудительная очистка устаревших сессий старше 24 часов:

DELETE FROM b_user_session
WHERE DATE_CREATE < DATE_SUB(NOW(), INTERVAL 24 HOUR);

DELETE FROM b_sale_user_session
WHERE DATE_INSERT < DATE_SUB(NOW(), INTERVAL 7 DAY);

Журнал событий

b_event_log — таблица аудита действий пользователей. На активных сайтах добавляет миллионы записей в месяц. Большинству проектов не нужны события старше 90 дней.

DELETE FROM b_event_log WHERE DATE_CREATE < DATE_SUB(NOW(), INTERVAL 90 DAY);
OPTIMIZE TABLE b_event_log;

Настройка автоматической очистки: Настройки → Журнал событий → Очистить события → Хранить события за последние N дней.

Таблицы статистики

Модуль statistic заполняет b_stat_session, b_stat_page_adv, b_stat_adv_back. Если статистика не используется (многие переходят на Яндекс.Метрику), модуль можно отключить полностью: Настройки → Модули → Веб-аналитика → Отключить. Это прекращает запись и снимает нагрузку на БД.

Если отключить нельзя — настроить период хранения: Настройки → Веб-аналитика → Настройки → Глубина хранения статистики.

Оптимизация индексов и медленных запросов

Включите slow query log для выявления тяжёлых запросов. В my.cnf:

slow_query_log       = 1
slow_query_log_file  = /var/log/mysql/slow.log
long_query_time      = 1
log_queries_not_using_indexes = 1

Для Битрикс типичные узкие места:

Настройка innodb_buffer_pool_size

Для MySQL/MariaDB самый важный параметр производительности — innodb_buffer_pool_size. Для сервера, выделенного под БД, устанавливайте 60–70% от доступной RAM:

innodb_buffer_pool_size = 4G   # для сервера с 8 GB RAM
innodb_log_file_size    = 512M
innodb_flush_log_at_trx_commit = 2   # чуть меньше гарантий, но значительно быстрее

innodb_flush_log_at_trx_commit = 2 допускает потерю до 1 секунды транзакций при аварийном отключении питания, но даёт прирост производительности записи в 2–5 раз. Для большинства e-commerce приемлемо.

Регламент обслуживания БД

Сроки работ