Ускорение MySQL и MariaDB для Битрикс: настройка без апгрейда

MySQL и MariaDB: настройка для 1С-Битрикс без тормозов

Мы часто сталкиваемся с ситуацией: сервер с 32 ГБ RAM, но MySQL использует только 2 ГБ. Дефолтный innodb_buffer_pool_size — 128 МБ или даже 8 МБ. На каталоге с 500 000 SKU рабочий набор данных — 4–8 ГБ. Без нормального буфера каждый запрос к незакэшированным страницам идёт на диск: 5–10 мс вместо 0,1 мс из памяти. Результат — страницы грузятся по 10–15 секунд, администраторы жалуются, клиенты уходят. Настройка MySQL и MariaDB для Битрикс — это задача, которую мы решаем регулярно. Экономия на оборудовании за счёт грамотной конфигурации составляет до 30% бюджета на хостинг.

Почему настройка MySQL критична для Битрикс?

Битрикс активно использует InnoDB для хранения инфоблоков, торговых каталогов, свойств и событий. При дефолтной конфигурации база данных становится узким местом, даже если остальные ресурсы сервера избыточны. Мы оптимизировали MySQL для десятков проектов на Битрикс и знаем, какие параметры дают максимальный прирост. Снижение нагрузки на диск также снижает затраты на поддержку и продление.

Правильная настройка InnoDB buffer pool

Размер буфера — самый важный параметр. Установите 60–70% от RAM для выделенного DB-сервера. Для 32 ГБ это 20 ГБ. Добавьте несколько буферных пулов, чтобы уменьшить конкуренцию за мьютекс: innodb_buffer_pool_instances = 8. Если у вас 64 ГБ RAM, можно 40–45 ГБ с 8–16 инстансами. На серверах с высокой конкурентностью количество пулов должно быть примерно равно числу ядер CPU. Это даёт прирост до 20% в многопоточных нагрузках.

Параметры InnoDB: Файл /etc/mysql/conf.d/bitrix.cnf:

[mysqld] # ===== InnoDB Buffer Pool ===== # 60-70% от RAM для выделенного DB-сервера innodb_buffer_pool_size = 20G innodb_buffer_pool_instances = 8 # ~1 instance per 1-2GB # ===== InnoDB I/O ===== innodb_io_capacity = 2000 # для SSD: 2000-4000 innodb_io_capacity_max = 4000 innodb_flush_method = O_DIRECT # обход OS page cache innodb_flush_log_at_trx_commit = 2 # не fsync на каждую транзакцию # ===== Redo Log ===== # MySQL 8.0+: управляется автоматически # MariaDB / MySQL 5.7: innodb_log_file_size = 1G innodb_log_buffer_size = 64M # ===== Connections ===== max_connections = 500 thread_cache_size = 50 wait_timeout = 300 interactive_timeout = 300 # ===== Query Cache ===== # MySQL 8.0: Query Cache удалён # MariaDB / MySQL 5.7: отключаем (лучше использовать Memcached/Redis) query_cache_type = 0 query_cache_size = 0 # ===== Temp Tables ===== tmp_table_size = 256M max_heap_table_size = 256M # ===== Slow Log ===== slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = 1 

innodb_flush_log_at_trx_commit = 2 — транслог сбрасывается на диск раз в секунду, не при каждом COMMIT. Риск потери транзакций за 1 секунду при сбое — приемлемо для большинства интернет-магазинов. Даёт 3–5x рост записи. innodb_flush_method = O_DIRECT — MySQL пишет напрямую в блочное устройство, минуя OS page cache. Исключает двойное кэширование.

Что даёт настройка для NVMe SSD?

На современных NVMe дисках можно агрессивнее:

innodb_io_capacity = 10000 innodb_io_capacity_max = 20000 innodb_read_io_threads = 8 innodb_write_io_threads = 8 

Это увеличивает пропускную способность до 30% по сравнению с обычным SSD. Например, недавно мы настроили сервер клиента с каталогом 200 000 товаров — время генерации страницы снизилось с 12 до 2 секунд.

Сравнение производительности при разных конфигурациях:

Таблицы Битрикс: специфика

b_search_content — полнотекстовый индекс. Таблица растёт до 2–5 ГБ на крупных сайтах. Если используется Elasticsearch — эту таблицу можно усечь и отключить встроенную индексацию.

b_iblock_element_prop_m* — множественные свойства. При 1М+ строк без индексов — тормоз умного фильтра. Мы добавляем индексы по полям IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID.

b_event — лог событий системы. На активных сайтах растёт на 10–50 МБ в сутки. Чистить через агент или крон:

DELETE FROM b_event WHERE DATE_COLUMN < DATE_SUB(NOW(), INTERVAL 90 DAY); 

Также обратите внимание на b_catalog_price и b_sale_basket — без индексов они сильно замедляют работу корзины и прайс-листов.

Как проверить эффективность настройки?

Мониторинг состояния InnoDB:

-- Эффективность buffer pool (должна быть > 99%) SELECT (1 - ( (SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads') / (SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests') )) * 100 AS buffer_pool_hit_rate; -- Топ ожиданий SELECT * FROM sys.innodb_lock_waits; 

buffer_pool_hit_rate < 95% — innodb_buffer_pool_size слишком мал, данные постоянно читаются с диска.

Ключевые параметры MySQL для Битрикс: дефолт против оптимизации

Процесс работы

1. Аналитика — сбор текущей конфигурации, профилирование нагрузки, измерение времени запросов.
2. Проектирование — подбор параметров под ваш объём данных, трафик и оборудование.
3. Реализация — изменение конфигурационных файлов, рестарт MySQL (5-10 секунд простоя) или применение параметров через SET GLOBAL.
4. Тестирование — проверка через slow log, мониторинг buffer pool hit rate, исправление индексов.
5. Деплой — финальная настройка и документирование.

Что входит в результат

• Оптимизация параметров MySQL/MariaDB под вашу версию и нагрузку.
• Проверка и донастройка индексов на таблицах Битрикс.
• Включение slow log и инструкция по анализу.
• Отчёт с аргументацией каждого параметра.
• Поддержка 7 дней после настройки.
• Экономия на оборудовании за счёт повышения производительности.

Мы имеем 5+ лет опыта в настройке MySQL для Битрикс и провели оптимизацию на более чем 50 проектах. Гарантируем прирост производительности базы данных в 3-5 раз.

Закажите аудит базы данных прямо сейчас — мы подберём оптимальную конфигурацию под ваши задачи. Получите консультацию по настройке вашего сервера — свяжитесь с нами для аудита.

Подробнее о InnoDB на Wikipedia