Производительность запросов в 1С
Тема дорожной карты · 1C Developer
Производительность запросов 1С — самая частая причина медленной работы прикладных решений в проде. Платформа транслирует запросы языка 1С в SQL под используемую СУБД (PostgreSQL, MS SQL, Oracle); неэффективный 1С-запрос становится неэффективным SQL, который на больших регистрах (миллионы движений) превращает форму списка в несколько секунд ожидания. Анализ требует тройного зрения: план запроса в Конфигураторе/EDT, реальный SQL в профайлере СУБД и индексы под виртуальные таблицы. Стандартный набор инструментов: КонсольЗапросов, отладка плана через ПоказатьЗапрос, СУБД-профайлер (SQL Server Profiler / pg_stat_statements).
Как это работает
Запрос 1С перед выполнением проходит несколько стадий: разбор → построение плана платформой → трансляция в SQL → выполнение на СУБД → возврат набора данных в платформу → конвертация в типы 1С. Узкие места обычно: соединения по неиндексированным полям, виртуальные таблицы Остатки, Обороты без правильных параметров (отбор по периоду и измерениям), вложенные подзапросы вместо временных таблиц, запросы внутри циклов на регистрах. Помещение ВЫБРАТЬ с ПОМЕСТИТЬ во временную таблицу + индексирование через ИНДЕКСИРОВАТЬ ПО ускоряет последующие шаги пакета в разы.
Когда применять
Оптимизировать запрос нужно сразу, как только профайлер показывает > 100 мс на типовом наборе данных или ApdexBundle падает на отчётах. Для типовых конфигураций (ЕРП, УТ) у вендора есть тех.доки по оптимизации каждого регистра — читайте их прежде, чем переписывать с нуля. На развитой инфраструктуре подключите APDEX-мониторинг (1С:КИП), который автоматически ловит регрессии после релизов.
Типичные ошибки
Самая болезненная: соединения с виртуальной таблицей Остатки() без отбора в её параметрах — платформа считает остатки по ВСЕЙ таблице, а потом фильтрует. Отбор в ГДЕ после соединения работает в десятки раз медленнее, чем тот же отбор внутри параметров виртуальной таблицы. Вторая: запросы в цикле для проверки прав или подгрузки реквизитов — N+1 пробл, прямой путь к секундам ожидания. Третья: использование оператора В с большим массивом значений в СоединениеЛевое — СУБД генерирует огромный план.