Оптимизация SQL-запросов на Битрикс: ищем и переписываем тяжёлые запросы

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

Почему именно запросы становятся узким местом

1С-Битрикс — это богатая платформа со множеством абстракций: инфоблоки, компоненты, ORM, выборки getList. Они удобны для разработки, но легко порождают неоптимальные обращения к базе, если их применять без оглядки на план выполнения. Самый частый сценарий — запрос внутри цикла: код перебирает список товаров или заказов и на каждой итерации лезет в базу за деталями. На десяти элементах это незаметно, на тысяче — страница встаёт. Второй частый случай — фильтр по неиндексированному свойству инфоблока: база вынуждена прочитать всю таблицу свойств целиком, чтобы отобрать нужные строки. Третий — выборка по всем полям и без лимитов, когда из базы тянутся данные, которые тут же отбрасываются.

Все эти проблемы объединяет одно: они почти не видны в коде и проявляются только под объёмом данных и трафиком. Поэтому их нельзя найти на глаз — нужны измерения. Slow query log показывает, какие запросы выполняются дольше порога и как часто, а EXPLAIN раскрывает, почему конкретный запрос медленный: читает по индексу или сканирует таблицу, сколько строк перебирает, создаёт ли временные таблицы. Без этих инструментов оптимизация превращается в гадание, а с ними — в инженерную работу с предсказуемым результатом.

Что меняет адресная оптимизация

Адресная оптимизация бьёт не по всему подряд, а по тем нескольким запросам, которые дают основной вклад в медленную работу. На типичном проекте достаточно переписать три-пять самых тяжёлых обращений, чтобы страница, открывавшаяся секундами, начала отвечать за десятки миллисекунд. Мы убираем запросы из циклов, собирая данные одной выборкой. Переводим фильтры на индексируемые поля и добавляем недостающие индексы. Чистим выборки от лишних полей и строк. Кешируем результаты там, где данные меняются редко. И переписываем сами SQL-запросы по плану EXPLAIN, убирая лишние соединения и подзапросы. Каждое изменение проверяется замером: видно, как упало время и число прочитанных строк.

Важно, что оптимизация запросов — это часть более широкой работы по ускорению. Если узкое место не только в базе, но и в кеше, верстке или сервере, мы подключаем смежные направления. Глубокая настройка самой СУБД, индексов на уровне сервера и параметров движка — это оптимизация MySQL и PostgreSQL для Битрикс, которая хорошо дополняет переписывание запросов. А если нужно сперва точно понять, какие именно запросы тормозят и сколько их, начинают с услуги аудит медленных SQL-запросов на Битрикс — на нём собирается полная картина по slow query log и строится план. Все эти услуги относятся к направлению база данных и запросы, и мы подбираем нужную комбинацию под конкретный проект.

Чем переписывание запросов отличается от наращивания железа

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

Со штатным программистом ситуация мягче, но риск тот же: без замеров и понимания планов выполнения правки делаются наугад. Добавили индекс на всё подряд — замедлили запись и раздули базу. Переписали запрос на ощупь — изменили логику и получили баг. Мы работаем иначе: сначала измеряем, потом меняем, потом снова измеряем. Каждое решение подтверждается данными до и после, поэтому ни логика проекта, ни его обновляемость не страдают.

Когда оптимизация запросов окупается, а когда хватит малого

Мы не уговариваем всех подряд заказывать глубокую оптимизацию. Она оправдана, когда база реально стала узким местом: страницы тормозят под объёмом данных, сервер базы регулярно показывает высокую нагрузку, slow query log полон тяжёлых запросов. В этом случае переписывание окупается ускорением страниц, снятой нагрузкой и отложенным апгрейдом железа. Если же проект небольшой, данных немного, а тормозит он по другой причине — например, из-за выключенного кеша или медленного хостинга, — иногда достаточно точечной правки, и городить полноценную оптимизацию запросов не нужно. На бесплатном аудите мы честно говорим, в чём корень проблемы и что выгоднее сделать в первую очередь.

Как мы ведём работу

Старт — это снятие базовых метрик. Мы включаем сбор медленных запросов, профилируем типовые страницы и фиксируем текущее время ответа и нагрузку на базу. Без этой точки отсчёта невозможно доказать эффект, поэтому мы всегда начинаем с измерений. Дальше строим список самых дорогих и частых запросов и разбираем каждый через EXPLAIN: смотрим тип доступа, число прочитанных строк, использование индексов и временных таблиц. На основе этого решаем, что делать с конкретным запросом — добавить индекс, переписать выборку, убрать N+1 или закешировать результат.

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

Сценарии, под которые мы оптимизируем

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

Для B2B-портала и личных кабинетов узким местом чаще оказывается N+1: страница кабинета собирает заказы, документы и взаиморасчёты контрагента запросами в цикле. Мы заменяем их одной выборкой по списку, и страница, открывавшаяся секундами, начинает летать. Для HighLoad-проектов на первый план выходит пиковая нагрузка на сервер базы: в часы пик база упирается в процессор или диск из-за нескольких частых тяжёлых запросов. Их переписывание и кеширование снимают пик и позволяют держать рост трафика без апгрейда железа.

Чем точечная оптимизация выгоднее альтернатив

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

Именно поэтому мы начинаем с измерений и идём по приоритету. Вы платите за работу по тем запросам, которые реально тормозят, а не за абстрактное улучшение всего сразу. Эффект виден сразу и подтверждается метриками, а вложения окупаются ускорением страниц и снятой нагрузкой на базу. Когда данных и трафика становится больше, переписанные запросы продолжают работать быстро, и проект не упирается в потолок там, где раньше вставал.

Гарантии и прозрачность

Объём работ и стоимость мы фиксируем после короткого аудита slow query log, чтобы вы понимали, за что платите. Каждое изменение сопровождается замером до и после: видно, как изменился план выполнения, время ответа и нагрузка. Мы не правим ядро Битрикса напрямую и не делаем рискованных изменений без подтверждения метриками, поэтому логика и обновляемость проекта сохраняются. По итогам вы получаете отчёт с переписанными запросами, добавленными индексами и прозрачными цифрами прироста. Развивать проект дальше сможет как наша команда, так и ваши разработчики — мы передаём не только результат, но и понимание, как его сохранить. Отдельно фиксируем, какие места кода чаще всего порождали тяжёлые запросы, и даём короткий чек-лист для код-ревью, чтобы новые фичи не возвращали базу в прежнее состояние. При желании настраиваем регулярный мониторинг медленных запросов, который заранее подсвечивает деградацию, пока она не стала заметной пользователям.

Возражения, которые мы слышим чаще всего

«У нас уже стоит мощный сервер, зачем оптимизировать запросы». Мощный сервер ускоряет всё на время, но не лечит причину: неоптимальный запрос читает лишние строки и снова упрётся в потолок с ростом данных. Оптимизация делает запрос быстрым в принципе, а не за счёт временного запаса железа. «Боимся, что переписывание сломает логику». Мы меняем запросы измеримо и аккуратно, сверяя результат до и после, и не трогаем ядро напрямую — риск поломки минимален, а каждое изменение откатываемо. «Это надолго и дорого». Наоборот: адресная работа по нескольким тяжёлым запросам обычно занимает дни, а не месяцы, и даёт прирост скорости, который виден сразу и сохраняется надолго.

С чего начать

Начните с аудита. Дайте нам доступ к проекту или его копии — мы включим slow query log, соберём список тяжёлых запросов и покажем, что именно тормозит и насколько. По итогам вы получите честную картину: какие запросы дают основную задержку, что переписать в первую очередь, какой прирост это даст и за какой срок. Аудит медленных запросов проводим без обязательств, а дальше вы решаете, делать оптимизацию своими силами по нашему плану или доверить её нам. Обсудим ваш проект — и превратим базу данных из узкого места в незаметный быстрый слой, который спокойно держит рост.