Какой вариант запроса в 1С работает быстрее: фильтрация или избыточное соединение?

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

Анализ задачи

Рассмотрим два варианта получения данных, которые возвращают идентичный результат:

Вариант 1 (Стандартный):

ВЫБРАТЬ
    ЗаказПокупателя.Ссылка КАК ЗаказПокупателяПоОснованию
ИЗ
    Документ.ЗаказПокупателя КАК ЗаказПокупателя
ГДЕ
    ЗаказПокупателя.ДокументОснование = &Основание

Вариант 2 (Через избыточное соединение):

ВЫБРАТЬ
    ЗаказПокупателя.Ссылка КАК ЗаказПокупателяПоОснованию
ИЗ
    Документ.ЗаказПокупателя КАК ЗаказПокупателя
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ЗаказПокупателя КАК ЗаказПокупателяДляФильтра
    ПО ЗаказПокупателя.ДокументОснование = &Основание
    И ЗаказПокупателя.Ссылка = ЗаказПокупателяДляФильтра.Ссылка

Почему первый вариант оптимальнее?

Давайте разберем, что происходит на стороне СУБД при выполнении каждого из этих запросов. Вариант 1 является классическим способом фильтрации данных. Современный оптимизатор запросов СУБД (будь то Microsoft SQL Server, PostgreSQL или IBM DB2) настроен на максимально эффективное выполнение инструкций типа SELECT ... WHERE.

Когда вы используете секцию ГДЕ, платформа 1С передает СУБД четкое условие отбора. В этом случае:

1. СУБД оценивает наличие индекса по полю ДокументОснование.
2. Если индекс существует, выполняется операция Index Seek (поиск по индексу), что является максимально быстрым способом получения данных.
3. Если индекс отсутствует, выполняется Table Scan (сканирование таблицы), что является базовым уровнем затрат ресурсов.

Вариант 2 добавляет к выполнению запроса неоправданную нагрузку. Соединение таблицы самой с собой (Self-Join) в данном контексте не несет никакой смысловой нагрузки. При этом:

• Создаются дополнительные промежуточные структуры данных для выполнения операции JOIN.
• Тратится процессорное время на сопоставление записей по полю Ссылка, хотя эти данные уже определены в первом наборе.
• Повышается потребление оперативной памяти, так как СУБД вынуждена хранить состояние обеих виртуальных таблиц.

Ключевые рекомендации по оптимизации

Чтобы наши запросы всегда выполнялись быстро, важно соблюдать несколько правил:

1. Не усложняйте без нужды. Избыточные соединения — главный враг производительности. Если данные можно получить из одной таблицы одним условием, всегда выбирайте именно этот путь.
2. Используйте индексы. Если часто выполняется отбор по полю ДокументОснование, убедитесь, что это поле добавлено в индекс. В 1С это достигается настройкой соответствующих параметров в конфигураторе (например, создание индекса в объекте конфигурации или использование критериев отбора).
3. Анализируйте дополнительные фильтры. Если таблица документов содержит миллионы записей, даже с индексом выборка может быть долгой. Добавление уточняющих условий, таких как Дата (например, ЗаказПокупателя.Дата >= &ДатаНачала), позволит СУБД существенно сократить область поиска данных.

Вывод

Проанализировав ситуацию, мы пришли к однозначному выводу: первый запрос является предпочтительным. Он чист, понятен и не содержит избыточных операций соединения, которые лишь «засоряют» план выполнения запроса. Использование конструкции ГДЕ для фильтрации — это правильный и наиболее эффективный путь в разработке на платформе 1С. Второе решение — это пример «дичи», которая лишь неоправданно увеличивает время работы системы и нагрузку на сервер баз данных.