Оптимізація бази даних 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 прийнятно.

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

Тривалість робіт