Налаштування Query Cache MySQL для 1С-Бітрікс

Налаштування та оптимізація Query Cache під Бітрікс

Query Cache у MySQL — механізм кешування результатів SELECT-запитів в оперативній пам'яті. Звучить як очевидне покращення, але на практиці неправильно налаштований Query Cache стає вузьким місцем, а не прискоренням: при будь-якому INSERT/UPDATE/DELETE у таблицю MySQL інвалідує всі кешовані запити до цієї таблиці, що при високій частоті запису перетворюється на постійні скидання кешу і деградацію продуктивності.

Для Бітрікс завдання полягає в тому, щоб правильно визначити, чи потрібен Query Cache взагалі, і якщо потрібен — налаштувати його під реальний профіль навантаження.

Коли Query Cache допомагає, а коли шкодить

Query Cache ефективний при високому співвідношенні читань до записів (>10:1), стабільному каталозі з рідкісними оновленнями цін і залишків, відносно невеликому наборі запитів, що повторюються.

Query Cache шкідливий при активній торгівлі з частими оновленнями 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 для Бітрікс

query_cache_type = 1               # ON
query_cache_size = 256M            # не більше 512M — вище не дає ефекту
query_cache_limit = 2M             # максимальний розмір одного результату
query_cache_min_res_unit = 4096    # мінімальний блок алокації

Критично важливо: query_cache_size більше 512 МБ на практиці знижує продуктивність через фрагментацію і накладні витрати на управління кешем. Оптимум для більшості Бітрікс-сайтів — 128–256 МБ.

Моніторинг ефективності

Після увімкнення дивимося на статусні змінні:

SHOW GLOBAL STATUS LIKE 'Qcache%';

Ключові метрики:

• Qcache_hits / (Qcache_hits + Com_select) — hit rate, має бути >30% для позитивного ефекту
• Qcache_lowmem_prunes — кількість видалень через нестачу пам'яті; якщо зростає швидко — збільшуємо query_cache_size
• Qcache_not_cached — запити, що не потрапили в кеш (некешовані запити: з SQL_NO_CACHE, NOW(), RAND() тощо)

Бітрікс активно використовує NOW() у запитах до дат публікації матеріалів — такі запити не кешуються за визначенням.

Що ми робимо в рамках послуги

Аналізуємо профіль навантаження через pt-query-digest і статусні змінні. Визначаємо співвідношення read/write для ключових таблиць Бітрікс. На основі аналізу приймаємо рішення: увімкнути Query Cache з конкретними параметрами, відключити його на користь Memcached/Redis, або перевести окремі запити на SQL_NO_CACHE.

Налаштовуємо конфігурацію, перевіряємо hit rate після прогріву під реальним навантаженням, при необхідності калібруємо query_cache_size і query_cache_limit.

Результат

Коректно налаштований Query Cache знижує навантаження на CPU сервера БД на 15–40% на сайтах із переважанням читань. На високонавантажених магазинах з частими записами — відключення некоректно працюючого Query Cache знижує latency запитів на 20–30%.