Оптимизация Highload-блоков на Битрикс для миллионов записей

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

Почему большой справочник начинает тормозить

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

Вторая причина — тяжёлые выборки. Типичная ошибка: ORM-выборка тянет все поля справочника и связанные сущности, хотя странице нужны два-три значения. База честно собирает весь объём, передаёт его в PHP, тот раздувает память и время ответа. Когда такая выборка вызывается на каждой странице каталога, а кеша нет, нагрузка растёт пропорционально трафику. Третья причина — связка с каталогом: фасетный фильтр строит условия по полям Highload-блока, и одна медленная выборка по справочнику тормозит уже не строку, а всю витрину, которую ждёт пользователь.

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

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

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

Чем системная оптимизация отличается от точечной правки

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

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

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

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

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

Связка с каталогом и фильтром

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

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

«У нас всего пара миллионов записей, разве это много для Highload-блока». Дело не в абсолютном числе, а в том, есть ли под запросы индексы и какие выборки идут по справочнику. Без индексов и миллион строк тормозит, а с правильной структурой и десяток миллионов отвечает мгновенно. Мы смотрим не на размер таблицы, а на то, как проект к ней обращается.

«Боимся менять типы полей на работающем проекте». Это разумная осторожность, и мы её разделяем. Поэтому миграции делаем на копии, проверяем, что данные конвертируются без потерь, и переносим изменения на боевой сайт только после сверки. Перевод строковых полей в числа и даты обычно сразу ускоряет сравнения и сортировки и не несёт рисков, если выполнен аккуратно.

«Поставим индекс — и всё ускорится». Иногда да, но часто индекс не совпадает с условием запроса или его перебивает приведение типов, и выборка остаётся медленной. Поэтому мы строим индексы по плану запроса, а не по интуиции, и проверяем, какой индекс реально используется базой. Калькулятор на этой странице помогает заранее прикинуть, сколько времени ожидания вернёт ускорение в вашем случае.

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

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

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

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

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

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

Этапы работы по шагам

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

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

Что вы получаете по итогу

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

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