Ви помічали, що після додавання нового товару до каталогу сайт на кілька секунд «замислюється»? Або що сторінки з фільтрами завантажуються швидше, але періодично просідають? Цілком імовірно, що проблема в стандартному механізмі кешування запитів MySQL — Query Cache. На неправильних налаштуваннях він замість прискорення спричиняє постійні інвалідації кешу та зростання latency. Ми — команда з 10-річним досвідом підтримки Бітрікс-проєктів — розберемо, як витягти з Query Cache максимум без підводних каменів. За 3 робочих дні налаштуємо конфігурацію під ваш профіль навантаження, гарантуємо приріст продуктивності. Наш досвід — понад 50 успішних оптимізацій для інтернет-магазинів і корпоративних порталів на Бітрікс. Економія серверних ресурсів до 40% дозволяє знизити витрати на хостинг на $50-200 на місяць для середнього проєкту.
Коли Query Cache допомагає, а коли шкодить?
Query Cache ефективний при високому співвідношенні читань до записів (більше 10:1), стабільному каталозі з рідкісними оновленнями цін і залишків, відносно невеликому наборі повторюваних запитів. Шкодить при активній торгівлі з частими оновленнями b_catalog_store_product і b_catalog_price, при використанні агентів Бітрікс із записом до БД щохвилини, при реплікації master-slave (Query Cache не реплікується, створює розбіжності).
Важливо: у MySQL 8.0 Query Cache повністю видалено. MariaDB зберегла його як опціональний компонент. Якщо працюєте на MySQL 8.0+, альтернатива — ProxySQL Query Cache або кешування на рівні застосунку через Redis/Memcached. Правильно налаштований Query Cache знижує навантаження на БД у 2-3 рази порівняно з неоптимізованою конфігурацією.
Як визначити профіль навантаження?
Використовуємо pt-query-digest для збору всіх запитів за період, аналізуємо співвідношення read/write для ключових таблиць Бітрікс: b_catalog_price, b_catalog_store_product, b_iblock_element, b_sale_basket. Якщо кількість запитів на оновлення перевищує 10% від загальної кількості, Query Cache скоріше за все принесе більше шкоди.
Наприклад, в одному проєкті інтернет-магазину з 200 000 товарів і частими оновленнями залишків (кожні 15 хвилин) увімкнений Query Cache викликав падіння hit rate до 5% і зростання часу відповіді вдвічі. Після вимкнення latency знизився на 25%.
Які параметри конфігурації оптимальні?
Рекомендовані налаштування для Бітрікс:
| Параметр | Значення | Коментар |
|---|---|---|
| query_cache_type | 1 (ON) | Вмикаємо |
| query_cache_size | 256M | Не більше 512M, оптимум 128-256M |
| query_cache_limit | 2M | Максимальний розмір одного кешованого запиту |
| query_cache_min_res_unit | 4096 | Мінімальний блок виділення пам'яті |
За даними MariaDB Knowledge Base, розмір кешу не повинен перевищувати 512 МБ, оскільки більший об'єм призводить до фрагментації та падіння продуктивності. Тюнінг MySQL для Бітрікс часто починають з Query Cache.
Рекомендації для різних типів навантаження:
| Тип навантаження | Дія з Query Cache | Альтернатива |
|---|---|---|
| Переважно читання (каталог, вітрина) | Увімкнути 256M, ліміт 2M | — |
| Активні оновлення (інтернет-магазин, CRM) | Вимкнути | ProxySQL Cache / Redis |
| Змішана, з реплікацією | Вимкнути або використовувати MariaDB | Кеш на рівні застосунку |
Чому моніторинг такий важливий?
Після ввімкнення дивимося статусні змінні:
SHOW GLOBAL STATUS LIKE 'Qcache%'; Ключові метрики:
| Метрика | Опис | Цільове значення |
|---|---|---|
| Qcache_hits / (Com_select) | Hit rate | >30% |
| Qcache_lowmem_prunes | Витіснення через нестачу пам'яті | <10/min |
| Qcache_not_cached | Некешовані запити | Стабільно |
Моніторинг проводимо після прогріву протягом 1-2 годин під реальним навантаженням. Використовуємо Grafana + Prometheus для візуалізації. Детальніше читайте в документації MariaDB та Wikipedia.
Як виглядає процес роботи?
- Аналіз: збір логів, визначення профілю навантаження, оцінка поточної конфігурації.
- Проєктування: вибір стратегії (ввімкнення з параметрами, вимкнення, заміна на Redis/ProxySQL).
- Реалізація: налаштування конфігурації MySQL, зміна
my.cnf, перезапуск MySQL (якщо можливо без простою). - Тестування: під навантаженням, заміри продуктивності до та після.
- Документування: фіксація параметрів, інструкція з обслуговування.
Терміни виконання: від 1 до 3 робочих днів залежно від складності та доступності дампів. Наша компанія має 10+ років досвіду та 50+ реалізованих проєктів з налаштування MySQL для Бітрікс.
Що входить в послугу?
- Діагностика поточної конфігурації MySQL.
- Збір та аналіз профілю навантаження за допомогою
pt-query-digest. - Підбір оптимальних параметрів Query Cache (або обґрунтована відмова).
- Налаштування параметрів на сервері (без простою, з можливістю відкату).
- Звіт з результатами до та після.
- Рекомендації щодо подальшої оптимізації (якщо потрібна заміна на Redis/Memcached).
Типові помилки
- Встановлення
query_cache_sizeбільше 512 МБ — призводить до фрагментації. - Відсутність моніторингу hit rate — не можна оцінити ефективність.
- Увімкнення Query Cache на MySQL 8.0 — ця версія не підтримує його.
- Ігнорування реплікації — Query Cache не реплікується.
Правильне налаштування Query Cache знижує витрати на серверні ресурси на 20-40% за рахунок зменшення навантаження на CPU та диск. Налаштування MySQL для Бітрікс включає аналіз Query Cache. Зв'яжіться з нами для діагностики вашого Бітрікс-проєкту. Ми оцінимо поточне навантаження та запропонуємо оптимальні параметри. Гарантуємо приріст продуктивності або повернення до початкової конфігурації.