Сайт на Бітріксі почав гальмувати: сторінки каталогу завантажуються по 5–7 секунд, адміністративна панель зависає, оператори скаржаться на повільну роботу. Перше, на що варто звернути увагу — база даних. Типова картина: таблиці кешу розрослися до гігабайтів, сесії не чистилися роками, індекси фрагментовані, MySQL захлинається безкорисними запитами. Ми провели аудит БД для великого інтернет-магазину електроніки з 50 000 товарів і навантаженням 10 000 відвідувачів на день. Після очищення та налаштування конфігурації час генерації сторінки впав з 4.3 с до 1.1 с — результат — зростання конверсії на 12%. Економія на серверних ресурсах склала 70% за CPU та пам'яттю. Таке прискорення в 4 рази доступне кожному сайту на Бітріксі та окупається за місяць.
Чому таблиці кешу не очищуються автоматично?
У Бітрікс механізм кешування залишає теги в b_cache_tag, але не видаляє їх при скиданні кешу. Аналогічно з сесіями — b_user_session зберігає записи до явного DELETE. За рік ці таблиці можуть набрати сотні мегабайт сміття. Для діагностики виконайте SQL-запит:
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_cache_tag, b_search_content, b_file. Їх очищення — перший крок до прискорення.
Як самостійно провести первинну діагностику?
- Підключіться до БД через phpMyAdmin або консоль.
- Виконайте наведений вище запит — визначте, які таблиці займають найбільше місця.
- Увімкніть slow query log в MySQL і проаналізуйте повільні запити за добу.
- Перевірте розмір файлу
/var/lib/mysql/ibdata1— якщо він перевищує 10 ГБ при загальному об'ємі даних менше 2 ГБ, це сигнал до оптимізації. - Використовуйте
SHOW PROCESSLISTдля виявлення довгих запитів у реальному часі.
Прискорення повільних запитів через індекси
Увімкніть slow query log і аналізуйте запити без індексів. Для Бітрікс часті проблеми — відсутність індексів у b_iblock_element та b_sale_order. Додайте їх:
CREATE INDEX ix_active_iblock ON b_iblock_element (ACTIVE, IBLOCK_ID, TIMESTAMP_X); CREATE INDEX ix_user_status ON b_sale_order (USER_ID, STATUS_ID); Після створення індексів продуктивність вибірок зростає в 3–5 разів. Наприклад, для каталогу з 20 000 товарів час фільтрації за активністю скорочується з 2.1 с до 0.4 с.
Очищення таблиць кешу та сесій
Видаліть застарілі теги кешу та сесії:
DELETE FROM b_cache_tag WHERE SITE_ID IS NULL AND CACHE_SALT IS NULL; OPTIMIZE TABLE b_cache_tag; 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); Регулярне очищення цих таблиць скорочує їх розмір з гігабайтів до мегабайтів і знижує навантаження на MySQL.
Налаштування MySQL для максимальної продуктивності
Найважливіший параметр — innodb_buffer_pool_size. Для сервера з 8 ГБ RAM встановіть:
innodb_buffer_pool_size = 4G innodb_log_file_size = 512M innodb_flush_log_at_trx_commit = 2 innodb_flush_log_at_trx_commit = 2 дає приріст запису в 2–5 разів з мінімальною втратою надійності. Згідно з Вікіпедією, цей параметр критичний для продуктивності InnoDB. Додатково налаштуйте query_cache_type = 0 — у сучасних версіях MySQL він застарілий і лише сповільнює роботу.
Порівняння до та після оптимізації
| Показник | До оптимізації | Після оптимізації |
|---|---|---|
| Час генерації сторінки | 4.3 с | 1.1 с |
Розмір b_stat_session |
1.2 ГБ | 15 МБ |
| Навантаження на MySQL (CPU) | 85% | 25% |
| Кількість slow queries за годину | 120 | 3 |
| Середній час відповіді на запит | 0.8 с | 0.2 с |
Що входить у роботу
- Діагностика всіх таблиць та slow query log.
- Очищення кешу, сесій, журналу подій.
- Оптимізація індексів та фрагментованих таблиць.
- Налаштування my.cnf під навантаження.
- Регламент обслуговування (SQL-скрипти під cron).
- Консультація та підтримка протягом місяця після робіт.
Ми — команда сертифікованих Бітрікс-спеціалістів з досвідом понад 7 років. Провели 50+ аудитів, гарантуємо прискорення не менш ніж у 2 рази. Замовте консультацію — безкоштовно оцінимо поточний стан БД. Зв'яжіться з нами — отримайте детальний звіт з рекомендаціями.
Терміни робіт
| Масштаб | Склад | Термін |
|---|---|---|
| Базовий | Очищення кешу, сесій, подій, OPTIMIZE TABLE | 2–4 години |
| Повний | Аналіз slow queries, індекси, my.cnf, регламент | 1–2 дні |
Економія ресурсів сервера — до 70% навантаження на БД. Детальніше про методики читайте на Wikipedia.
Що робити, якщо після оптимізації БД сайт не працює?
Якщо після наших робіт сайт перестав відповідати, ймовірні причини — невірний параметр MySQL або помилковий DELETE. Ми завжди створюємо резервну копію перед змінами. Якщо ви виконували оптимізацію самостійно, відновіть дамп і зверніться до нас за допомогою.
Типові помилки при самостійній оптимізації
Найчастіша помилка — DELETE без WHERE або з неправильною умовою. Це може знищити важливі дані. Другий ризик — зміна параметрів MySQL без розуміння наслідків: наприклад, innodb_flush_log_at_trx_commit = 1 (безпечний, але повільний) проти = 2 (швидкий, але з можливою втратою 1 секунди даних при краху). Ми завжди створюємо резервну копію перед будь-якими змінами. Якщо сумніваєтеся — довірте аудит професіоналам. Зв'яжіться з нами для безкоштовної первинної діагностики.