Оптимизация базы данных 1С-Битрикс: почему сайт тормозит и что с этим делать

Когда интернет-магазин на 1С-Битрикс начинает отвечать медленнее, база данных часто оказывается частью проблемы, но далеко не всегда её единственной причиной. Такой же симптом дают медленный PHP-код, внешние API, блокировки файлов, нехватка процессов PHP-FPM и промахи кеша. Поэтому полезная оптимизация начинается с измерений, а не с запуска одной команды или установки «ускоряющего» модуля.

Ниже — порядок работы, который помогает отделить проблему базы от остальных узких мест, найти запросы с наибольшим влиянием и внести изменения так, чтобы не нарушить оформление заказа, обновление остатков и обмен с 1С.

Когда искать причину в базе данных

На участие базы указывают повторяемые признаки:

• одни и те же категории, фильтры или административные страницы стабильно медленнее остальных;
• время ответа растёт вместе с размером каталога, числом свойств, заказов или пользователей;
• во время обмена, переиндексации или работы агентов нагрузка на сервер БД заметно возрастает;
• в профиле запроса значительная доля времени приходится на SQL, ожидание блокировок или чтение большого числа строк;
• после прогрева кеша часть страниц становится быстрой, а страницы с персональными данными или сложными выборками остаются медленными.

Высокая загрузка CPU сама по себе ничего не доказывает. Важно связать конкретный URL или фоновую задачу с конкретными запросами и посмотреть, что сервер делает в этот момент.

Из чего складывается нагрузка на базу 1С-Битрикс

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

Рост таблицы тоже не означает, что её нужно немедленно «оптимизировать». Сначала выясняют, какие данные в ней находятся, почему они растут, используются ли в рабочих сценариях и есть ли утверждённый срок хранения. Удаление служебных данных без понимания назначения может повредить расследованию ошибок или работе модулей.

Диагностика: от страницы к запросу

1. Зафиксировать воспроизводимый сценарий

Выбирают несколько страниц и операций: категория с фильтром, карточка товара, поиск, корзина, оформление заказа, сохранение товара в административной части, импорт. Для каждой операции записывают время ответа, состояние кеша, тип пользователя и нагрузку на сервер. Анонимный просмотр прогретой страницы и оформление заказа авторизованным пользователем — разные сценарии, их нельзя смешивать в одном среднем значении.

2. Временно включить Монитор производительности

В 1С-Битрикс Монитор производительности умеет регистрировать SQL-запросы, сохранять стек вызовов и отдельно отбирать запросы, которые дольше заданного порога. Официальная документация ограничивает длительность такого сбора: полный журнал создаёт дополнительную нагрузку, поэтому его включают на контролируемый период и выключают после воспроизведения проблемы [1].

Стек вызова особенно полезен: одинаковый SQL может выполняться из разных компонентов, а исправлять нужно место в коде, которое создаёт лишние обращения.

3. Собрать slow query log на стороне MySQL или MariaDB

Slow query log фиксирует запросы, превысившие long_query_time. В MySQL журнал по умолчанию отключён; место вывода и порог задаются отдельно [2]. Порог выбирают по задаче: слишком высокий пропустит часто повторяющиеся задержки, слишком низкий быстро создаст большой журнал.

Журнал группируют по шаблону запроса и оценивают не только максимальное время, но и количество выполнений, суммарное время, просмотренные и возвращённые строки. Запрос по 80 мс, который выполняется тысячу раз, может быть важнее единичного запроса в две секунды.

4. Проверить план выполнения

EXPLAIN показывает выбранный план, порядок соединения таблиц и используемые индексы. EXPLAIN ANALYZE в поддерживаемых версиях MySQL действительно выполняет запрос и добавляет фактическое время и число строк [3]. На рабочей базе его применяют осторожно, особенно к изменяющим запросам и большим выборкам.

В плане ищут чтение существенно большего числа строк, чем возвращается пользователю, неэффективный порядок соединений, сортировки и временные таблицы. Вывод «нет индекса — добавим индекс» недостаточен: индекс должен соответствовать условиям WHERE, соединениям и сортировке конкретных рабочих запросов.

Какие изменения обычно дают результат

Исправление источника лишних запросов

Сначала убирают повторные выборки внутри циклов, загружают только нужные поля, объединяют однотипные обращения и устраняют N+1-запросы. Если компонент на каждой карточке товара отдельно получает одни и те же справочные данные, один кеш или общая выборка часто полезнее новой настройки сервера.

Индексы под реальные условия

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

Кеширование повторяемых чтений

Кеш уменьшает число одинаковых запросов, если данные допустимо переиспользовать и предусмотрен корректный сброс после изменения. В Bitrix Framework управляемый кеш очищается автоматически только в тех сценариях, где код связан с нужной таблицей или явно выполняет сброс [4]. Слишком долгий TTL без правил инвалидирования способен показать устаревшую цену или остаток.

Настройка MySQL или MariaDB по данным сервера

Параметры памяти и InnoDB сверяют с объёмом данных, доступной RAM, количеством соединений и остальными процессами на сервере. Универсального процента памяти для всех проектов нет. Изменения делают по одному блоку и отслеживают использование памяти, чтение с диска, ожидания и стабильность под нагрузкой.

Обслуживание таблиц только по показаниям

ANALYZE TABLE обновляет статистику, которую оптимизатор использует при выборе плана. В MariaDB документация рекомендует запускать анализ, когда заметно изменились объём или распределение данных, а не по произвольному частому расписанию [5]. OPTIMIZE TABLE нужен в отдельных случаях, например после удаления большой доли строк; операция может быть тяжёлой, поэтому её планируют с резервной копией и окном обслуживания [6].

Особенности обмена с 1С

Обмен одновременно пишет много данных, пересчитывает связи и очищает кеш. Ускорять его нужно отдельно от публичного каталога. Сначала определяют, какая фаза занимает время: приём файла, разбор, запись элементов, обновление свойств, цен и остатков, деактивация отсутствующих товаров или последующая переиндексация.

Изменения индексов и обработчиков проверяют на копии с реалистичным объёмом данных. После внедрения проводят полный и повторный обмен, проверяют цены, остатки, торговые предложения, изображения и доступность товаров. Быстрый импорт с нарушенной бизнес-логикой не считается результатом.

Как внедрять изменения безопасно

1. Сделать проверяемую резервную копию базы и зафиксировать исходные показатели.
2. Повторить проблему на тестовой копии или в согласованное окно.
3. Внести одно логически завершённое изменение.
4. Проверить план запроса, время и потребление ресурсов.
5. Прогнать ключевые сценарии магазина и обмена.
6. Оставить мониторинг на период реальной нагрузки и сравнить одинаковые интервалы.

Итогом работы должны быть не общие слова «база оптимизирована», а список найденных причин, выполненных изменений, планов до и после, результаты проверки функций магазина и рекомендации по наблюдению.

Источники

[1] 1С-Битрикс — настройки Монитора производительности: dev.1c-bitrix.ru/user_help/settings/perfmon/settings.php

[2] MySQL 8.4 Reference Manual — The Slow Query Log: dev.mysql.com/doc/refman/8.4/en/slow-query-log.html

[3] MySQL 8.4 Reference Manual — EXPLAIN Statement: dev.mysql.com/doc/refman/8.4/en/explain.html

[4] Bitrix Framework — кеширование: docs.1c-bitrix.ru/pages/performance/caching.html

[5] MariaDB Documentation — ANALYZE TABLE: mariadb.com/docs/server/reference/sql-statements/table-statements/analyze-table

[6] MariaDB Documentation — OPTIMIZE TABLE: mariadb.com/docs/server/ha-and-performance/optimization-and-tuning/optimizing-tables/optimize-table