Настройка 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%.