Как работает механика соединений в запросах 1С: разбираемся в алгоритмах СУБД

← На главную

Вопрос о том, как именно 1С "склеивает" таблицы в запросах, часто ставит в тупик даже опытных разработчиков. Кажется, что платформа должна иметь какой-то свой внутренний механизм, но на самом деле ситуация обстоит иначе. Разберем детально, что происходит "под капотом" при выполнении оператора ЛЕВОЕ СОЕДИНЕНИЕ или ВНУТРЕННЕЕ СОЕДИНЕНИЕ.

Кто на самом деле выполняет соединение?

Для начала проанализируем архитектуру системы. В клиент-серверном варианте платформа 1С выступает в роли транслятора. Когда мы пишем запрос на языке 1С, платформа переводит его на "родной" язык конкретной СУБД (T-SQL для MS SQL Server или PL/pgSQL для PostgreSQL). Сама 1С не выполняет физическое соединение таблиц — эта задача полностью ложится на плечи оптимизатора запросов СУБД.

Оптимизатор СУБД — это сложный программный комплекс, который на основе имеющейся статистики (данных о количестве строк, уникальности значений и распределении данных в индексах) строит план выполнения запроса. Рассмотрим основные алгоритмы, которые может выбрать СУБД для реализации вашего соединения.

Три основных алгоритма соединения

СУБД не использует один и тот же метод всегда. В зависимости от объема данных и наличия индексов выбирается наиболее дешевый (с точки зрения ресурсов) вариант:

Nested Loops (Вложенные циклы): Рассмотрим этот вариант как самый простой. СУБД берет строку из первой таблицы и ищет подходящую строку во второй. Если во второй таблице есть индекс по полю соединения, поиск происходит мгновенно. Это идеально подходит для случаев, когда одна таблица маленькая (например, 10 строк), а вторая большая, но проиндексированная.
Merge Join (Соединение слиянием): Этот алгоритм наиболее эффективен для больших объемов данных. Он требует, чтобы обе таблицы были заранее отсортированы по полям соединения. СУБД просто идет по двум спискам одновременно, как бы "сшивая" их. Если индексы обеспечивают нужную сортировку, этот метод работает быстрее всего.
Hash Join (Хэш-соединение): Если таблицы огромные, индексов нет и данные не отсортированы, СУБД строит в оперативной памяти временную хэш-таблицу для одной из таблиц, а затем сканирует вторую. Это ресурсоемкая операция, которая может замедлить сервер, если памяти не хватит и данные начнут записываться на диск.

Влияние индексов и статистики

Выясним причину, по которой один и тот же запрос может работать с разной скоростью. Все дело в индексах. В 1С важно понимать:

Если вы соединяете таблицу с Временной Таблицей, обязательно индексируйте поля соединения во временной таблице. Это позволит СУБД выбрать быстрый алгоритм Nested Loops.
Регулярно выполняйте регламентное задание "Обновление статистики". Если СУБД "думает", что в таблице 100 строк (хотя там уже миллион), она выберет неэффективный план, что приведет к зависанию системы.

Особенности разыменования ссылок (обращение через точку)

В 1С есть механизм, который неявно создает соединения — это обращение к реквизитам через точку. Проанализируем пример:


ВЫБРАТЬ
    Продажи.Номенклатура.Наименование,
    Продажи.Склад.Код
ИЗ
    РегистрНакопления.Продажи КАК Продажи

На уровне СУБД этот простой запрос превратится в конструкцию с двумя LEFT OUTER JOIN к таблицам справочников "Номенклатура" и "Склады". Рассмотрим подробнее опасность: если таких точек в запросе много, СУБД придется строить план для десятка соединений, что может перегрузить оптимизатор. Рекомендуется заменять множественные обращения через точку на явные соединения в тексте запроса, особенно если это касается высоконагруженных участков кода.

SARGability: как не "сломать" соединение

Посмотрим на типичную ошибку новичков — использование функций в условии соединения. Например:

ПО НАЧАЛОПЕРИОДА(Т1.Дата, ДЕНЬ) = НАЧАЛОПЕРИОДА(Т2.Дата, ДЕНЬ)

Такое условие делает запрос non-SARGable (Search Argumentable). Это означает, что СУБД не сможет использовать индекс по полю Дата, так как ей нужно сначала вычислить функцию для каждой строки таблицы. В итоге механика соединения деградирует до полного сканирования таблицы (Table Scan), что крайне медленно.

Файловый вариант базы данных

Разберем ситуацию с файловой базой. Здесь нет полноценного SQL-сервера, и используется собственный движок 1С. Его алгоритмы значительно проще и менее "интеллектуальны", чем у MS SQL или PostgreSQL. В файловом варианте практически всегда используется подобие вложенных циклов. Именно поэтому файловые базы так критично теряют в производительности при росте объема данных: отсутствие индекса на соединяемом поле заставляет систему выполнять полный перебор строк (квадратичная сложность).

Подведем итоги

Механика соединений в 1С — это механика используемой СУБД. Чтобы ваши запросы работали быстро, следуйте правилам:

Всегда индексируйте поля, по которым происходит соединение (особенно во временных таблицах).
Старайтесь использовать явные соединения вместо длинных цепочек "через точку".
Следите за актуальностью статистики в консоли администрирования СУБД.
Избегайте функций в условиях ПО, чтобы не блокировать использование индексов.

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