Вы замечали, что после добавления нового товара в каталог сайт на несколько секунд «задумывается»? Или что страницы с фильтрами грузятся быстрее, но периодически проседают? Вполне вероятно, что проблема в стандартном механизме кэширования запросов MySQL — Query Cache. На неправильных настройках он вместо ускорения вызывает постоянные инвалидации кэша и рост latency. Мы — команда с 7-летним опытом поддержки Битрикс-проектов — разберём, как извлечь из Query Cache максимум без подводных камней. За 3 рабочих дня настроим конфигурацию под ваш профиль нагрузки, гарантируем прирост производительности. Наш опыт — более 50 успешных оптимизаций для интернет-магазинов и корпоративных порталов на Битрикс.
Когда 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.
Как мы определяем профиль нагрузки
Используем 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% и рост времени ответа в 2 раза. После отключения 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 МБ, так как больший объём приводит к фрагментации и падению производительности.
Рекомендации для разных типов нагрузки:
| Тип нагрузки | Действие с 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 рабочих дней в зависимости от сложности и доступности дампов.
Что входит в услугу
- Диагностика текущей конфигурации 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 и диск. Свяжитесь с нами для диагностики вашего Битрикс-проекта. Мы оценим текущую нагрузку и предложим оптимальные параметры. Гарантируем прирост производительности или возврат к исходной конфигурации.