Предложение ВЫБРАТЬ (SELECT) в языке запросов 1С:Предприятия 8

В данной статье рассмотрено предложение ВЫБРАТЬ, его место и роль в языке запросов 1С:Предприятия 8.

Предложение ВЫБРАТЬ является единственным обязательным элементом любого запроса, поэтому изучение языка запросов начинается именно с него. Основная цель предложения ВЫБРАТЬ заключается в том, чтобы указать поля выборки, которые должны попасть в результат запроса.

Ниже рассмотрены следующие темы:

Место предложения ВЫБРАТЬ в структуре запроса

Структуру запроса 1С:Предприятия 8 можно представить в виде следующей схемы:

Из приведенной схемы можно сделать следующие выводы:

Примеры запросов с предложением ВЫБРАТЬ

1. Выборка всех полей (кроме виртуальных) из таблиц

Вместо перечисления списка полей можно указать звездочку («*») и тогда в результат запроса попадут все поля таблицы-источника, кроме виртуальных. Например:

//обращение к таблице справочника
ВЫБРАТЬ * ИЗ Справочник.Номенклатура

//обращение к таблице документа
ВЫБРАТЬ * ИЗ Документ.РасходныйКассовыйОрдер

//обращение к основной таблице регистра накопления
ВЫБРАТЬ * ИЗ РегистрНакопления.ПродажиКомпании

//обращение к виртуальной таблице регистра накопления
ВЫБРАТЬ * ИЗ РегистрНакопления.ПродажиКомпании.Обороты

Замечание: В языке запросов есть возможность обойтись без предложения ИЗ, если описание поля содержит полный путь к нему с указанием таблицы-источника, например,

//выборка всех невиртуальных полей из таблицы справочника
ВЫБРАТЬ Справочник.Номенклатура.*

//выборка определенных полей из таблицы справочника
ВЫБРАТЬ
Справочник.Номенклатура.Код,
Справочник.Номенклатура.Наименование,
Справочник.Номенклатура.Представление //виртуальное поле

2. Выборка только определенных полей из таблиц

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

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

//обращение к таблице документа
ВЫБРАТЬ Номер, Дата, ПодразделениеКомпании, СуммаДокумента
ИЗ Документ.РасходныйКассовыйОрдер

3. Виртуальные поля

Некоторые поля в таблицах-источниках виртуальные, например, поле «Представление» для таблицы справочника и документа, или поле «МоментВремени» для документа. Это значит, что они не хранятся в базе данных, а генерируются «на лету». Виртуальные поля не включаются в результат запроса, когда вместо списка полей указана звездочка («*»), их нужно указывать явно, например «ВЫБРАТЬ *, Представление ИЗ Справочник.Товары». Такое решение было принято для ускорения выполнения классического запроса «ВЫБРАТЬ * ИЗ. ». В этом случае не требуется генерировать представления для элементов справочников и документов, следовательно запросы будут выполняться быстрее.

//обращение к таблице справочника (выбрать два обычных поля и одно виртуальное)
ВЫБРАТЬ Код, Наименование, Представление
ИЗ Справочник.Номенклатура

//обращение к таблице документа (выбрать все невиртуальные поля и два виртуальных)
ВЫБРАТЬ *, Представление, МоментВремени
ИЗ Документ.РасходныйКассовыйОрдер

4. Разыменование ссылочных полей

В 1С:Предприятии 8 допускается обращение к свойствам объектов через одну или несколько точек, например, «Номенклатура.Поставщик.Страна». Это позволяет значительно упростить написание запросов. Рекомендуется всегда пользоваться разыменованием полей там, где это возможно, чтобы не усложнять запросы лишними конструкциями.

5. Псевдонимы полей (ключевое слово КАК / AS)

Для поля может быть назначен псевдоним с помощью ключевого слова КАК. Это позволяет обращаться к полю по псевдониму при указании итогов и порядка сортировки, а также при обходе выборки из результата запроса, например:

ВЫБРАТЬ
Ссылка КАК Документ,
Ответственный КАК МатериальноОтветственный
ИЗ Документ.АвансовыйОтчет
УПОРЯДОЧИТЬ ПО МатериальноОтветственный

Ключевое слово КАК является необязательным, то есть вышеприведенный запрос можно записать так:

ВЫБРАТЬ
Ссылка Документ,
Ответственный МатериальноОтветственный
ИЗ Документ.АвансовыйОтчет

6. Обращение к табличной части как вложенной таблице

В этом случае поле результата запроса будет иметь тип РезультатЗапроса, то есть содержать вложенный результат запроса, сформированный на основе табличной части.

//получение табличной части как вложенной таблицы результата запроса
ВЫБРАТЬ Номер, Дата, Товары
ИЗ Документ.АвансовыйОтчет

//получение нескольких колонок табличной части как вложенной таблицы
ВЫБРАТЬ Номер, Дата, Товары.(Номенклатура, Количество)
ИЗ Документ.АвансовыйОтчет

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

ВЫБРАТЬ Номер, Дата, Товары.Номенклатура, Товары.Количество
ИЗ Документ.АвансовыйОтчет

7. Обращение к табличной части как таблице-источнику

При таком способе обращения имя вложенной таблицы фигурирует в имени таблицы-источника (предложение ИЗ или полные имена полей) и в результате запроса нет вложенных таблиц.

//выборка всех полей из табличной части
ВЫБРАТЬ * ИЗ Документ.АвансовыйОтчет.Товары

// выборка определенных полей из табличной части
ВЫБРАТЬ Номенклатура, Количество, Цена, Сумма
ИЗ Документ.АвансовыйОтчет.Товары

//задание псевдонимов для полей табличной части
ВЫБРАТЬ Документ.АвансовыйОтчет.Товары.(Номенклатура, Сумма КАК СуммаПоСтроке)

//обращение к реквизитам документа и реквизитам табличной части (поле Ссылка)
ВЫБРАТЬ
Ссылка.Номер, Ссылка.Дата, Ссылка.Ответственный, //реквизиты документа
Номенклатура, Количество, Цена, Сумма //реквизиты табличной части
ИЗ Документ.АвансовыйОтчет.Товары

8. Ключевое слово РАЗЛИЧНЫЕ / DISTINCT

Ключевое слово РАЗЛИЧНЫЕ позволяет оставить в результате запроса только отличающиеся строки.

ВЫБРАТЬ РАЗЛИЧНЫЕ Ответственный
ИЗ Документ.АвансовыйОтчет

9. Ключевое слово ПЕРВЫЕ / TOP

Данное ключевое слово позволяет ограничить выборку несколькими первыми записями. Часто это ключевое слово применяется в комбинации с сортировкой (предложение УПОРЯДОЧИТЬ ПО).

ВЫБРАТЬ ПЕРВЫЕ 10 Номер, Дата, СуммаДокумента
ИЗ Документ.АвансовыйОтчет
УПОРЯДОЧИТЬ ПО СуммаДокумента УБЫВ

10. Выражения в списке полей выборки

В качестве описания поля выборки может быть выражение, использующее следующие элементы:

Ниже приведено несколько примеров с выражениями в списке полей выборки:

//арифметические операции
ВЫБРАТЬ
Номенклатура,
Количество * Цена КАК РасчСумма1,
Сумма / Количество КАК РасчСумма2
ИЗ Документ.АвансовыйОтчет.Товары

//литералы типа «булево», «число», «строка», «дата»
ВЫБРАТЬ Истина, Ложь, 10.5, «Текст», ДАТАВРЕМЯ(2003,12,25)

//конкатенация строк
ВЫБРАТЬ «Сотрудник » + Ответственный.Наименование
ИЗ Документ.АвансовыйОтчет

//агрегатные функции
ВЫБРАТЬ
ПодразделениеКомпании,
СУММА(СуммаДокумента),
МАКСИМУМ(СуммаДокумента),
МИНИМУМ(СуммаДокумента),
СРЕДНЕЕ(СуммаДокумента),
КОЛИЧЕСТВО(*)
ИЗ Документ.АвансовыйОтчет
СГРУППИРОВАТЬ ПО ПодразделениеКомпании

//операция выбора
ВЫБРАТЬ Наименование,
ВЫБОР
КОГДА СтранаПроисхождения.Наименование = «КИТАЙ» ТОГДА «Азия»
КОГДА СтранаПроисхождения.Наименование = «ТАЙВАНЬ» ТОГДА «Азия»
КОГДА СтранаПроисхождения.Наименование = «США» ТОГДА «Америка»
КОГДА СтранаПроисхождения.Наименование = «КАНАДА» ТОГДА «Америка»
ИНАЧЕ «Другое»
КОНЕЦ КАК Страна
ИЗ Справочник.Номенклатура

//операция приведения типов
ВЫБРАТЬ
Ссылка,
Номенклатура,
ВЫРАЗИТЬ(Сумма / 3 КАК Число(5,2)) КАК ТретьСуммы
ИЗ Документ.АвансовыйОтчет.Товары

Таким образом, предложение ВЫБРАТЬ является важнейшим элементом языка запросов, поскольку позволяет указать требуемые поля результата запроса. Гибкие возможности предложения ВЫБРАТЬ позволяют использовать язык запросов для решения самых разнообразных задач.

Источник

Все функции и конструкции языка запросов 1С 8.2 и 1с 8.3

В этой статье мы хотим обсудить с Вами все функции языка запросов 1с, а также конструкции языка запросов. Чем же отличается функция от конструкции? Функция вызывается со скобками и возможными параметрами в них, а конструкция пишется без скобок. Безусловно все конструкции и функции языка запросов 1с делают процесс получения данных гибким и многофункциональным. Данные функции и конструкции применимы к полям запроса, а некоторые также применимы в условиях.

Функции языка запросов 1с

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

Синтаксис: ВЫБОР КОГДА ТОГДА ИНАЧЕ КОНЕЦ

Синтаксис: ВЫРАЗИТЬ(НазваниеПоля КАК НазваниеТипа)

Еще есть вариант использования функции ВЫРАЗИТЬ в полях смешанных типах, где такие встречаются? Самый простой пример это «Регистратор» у любого регистра. Так зачем нам может понадобиться уточнять тип в регистраторе? Давайте рассмотрим ситуацию когда мы из регистратора выбираем поле «Номер», из какой таблицы будет выбран номер? Правильный ответ из всех! Поэтому чтобы наш запрос работал быстро следует указывать явный тип с помощью функции ВЫРАЗИТЬ

Также отметим что тип NULL желательно ВСЕГДА заменять на какое-то значение, т.к. сравнение с типом NULL всегда дает ЛОЖЬ даже если вы сравниваете NULL с NULL. Чаще всего значения NULL образуются в результате соединения таблиц (все виды соединений кроме внутреннего).

Конструкции в языке запросов 1с

Выше мы рассмотрели с Вами функции языка запросов 1с, теперь пришло время рассмотреть конструкции в языке запросов 1с, они не менее важны и полезны, приступаем.

Синтаксис: В( ), В ИЕРАРХИИ( )

Варианты шаблона строки:

Синтаксис: РАЗРЕШЕННЫЕ пишется после ключевого слова ВЫБРАТЬ

Синтаксис: РАЗЛИЧНЫЕ пишется после ключевого слова ВЫБРАТЬ

Также Конструкция РАЗЛИЧНЫЕ может использоваться с оператором РАЗРЕШЕННЫЕ и другими операторами.

Синтаксис: ДЛЯ ИЗМЕНЕНИЯ

Синтаксис: УПОРЯДОЧИТЬ ПО АВТОУПОРЯДОЧИВАНИЕ

Синтаксис: ИНДЕКСИРОВАТЬ ПО

Синтаксис: ИТОГИ ПО

На рисунке обведены группировки которые образовались в ходе выполнения запроса, самая верхняя относится к секции ОБЩИЕ, а вторая к полю ДоговорКонтрагентаВидДоговора.

Источник

Подзапросы с Выбрать Первые

Часто нужно использовать аналог Выбрать первые отсортированные по нескольким полям. Нашел решение такое

ВЫБРАТЬ ПЕРВЫЕ 1000
РеализацияТоваровУслуг.Ссылка,
ВложенныйЗапрос.НомерСтроки
ИЗ
Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
РеализацияТоваровУслугТовары.Ссылка КАК Ссылка,
РеализацияТоваровУслугТовары.НомерСтроки КАК НомерСтроки
ИЗ
Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ГДЕ
(РеализацияТоваровУслугТовары.Ссылка, РеализацияТоваровУслугТовары.НомерСтроки) В
(ВЫБРАТЬ ПЕРВЫЕ 1
Док.Ссылка,
Док.НомерСтроки КАК НомерСтроки
ИЗ
Документ.РеализацияТоваровУслуг.Товары КАК Док
ГДЕ
Док.Ссылка = РеализацияТоваровУслугТовары.Ссылка
УПОРЯДОЧИТЬ ПО
НомерСтроки УБЫВ,Количество УБЫВ)) КАК ВложенныйЗапрос
ПО РеализацияТоваровУслуг.Ссылка = ВложенныйЗапрос.Ссылка

УПОРЯДОЧИТЬ ПО
РеализацияТоваровУслуг.Дата

Что трансформируется в

SELECT TOP 1000
_Document196_Q_000_T_001._IDRRef AS f_2,
#V8TblAli1_Q_000_T_002._Q_001_F_001 AS f_3,
_Document196_Q_000_T_001._Date_Time AS _sf_1
FROM
_Document196 _Document196_Q_000_T_001 WITH(NOLOCK)
LEFT OUTER JOIN (
SELECT
_Document196_VT4933_Q_001_T_001._Document196_IDRRef AS _Q_001_F_000RRef,
_Document196_VT4933_Q_001_T_001._LineNo4934 AS _Q_001_F_001
FROM
_Document196_VT4933 _Document196_VT4933_Q_001_T_001 WITH(NOLOCK)
WHERE
EXISTS(
SELECT
CAST(1 AS NUMERIC(1,0)) AS f_1
FROM
(
SELECT TOP 1
_Document196_VT4933_Q_002_T_001._Document196_IDRRef AS _Q_002_F_000RRef,
_Document196_VT4933_Q_002_T_001._LineNo4934 AS _Q_002_F_001
FROM
_Document196_VT4933 _Document196_VT4933_Q_002_T_001 WITH(NOLOCK)
WHERE
_Document196_VT4933_Q_002_T_001._Document196_IDRRef = _Document196_VT4933_Q_001_T_001._Document196_IDRRef
ORDER BY
_Document196_VT4933_Q_002_T_001._LineNo4934 DESC,
_Document196_VT4933_Q_002_T_001._Fld4938 DESC
) #V8TblAli1
WHERE
_Document196_VT4933_Q_001_T_001._Document196_IDRRef = #V8TblAli1._Q_002_F_000RRef AND _Document196_VT4933_Q_001_T_001._LineNo4934 = #V8TblAli1._Q_002_F_001)
) #V8TblAli1_Q_000_T_002
ON _Document196_Q_000_T_001._IDRRef = #V8TblAli1_Q_000_T_002._Q_001_F_000RRef
ORDER BY
_Document196_Q_000_T_001._Date_Time

Но выполняется очень долго. Может есть более эффетивное решение

Источник

ВЫБРАТЬ ИЗ в запросе 1С 8.3

ВЫБРАТЬ

В предложении ВЫБРАТЬ указываются поля выборки запроса. Полей может быть несколько, между собой они разделяются запятой.

Можно использовать литералы примитивных типов:

С числами можно выполнять арифметические операции прямо в полях выборки:

Также можно использовать унарный минус:

Можно складывать строки, но только если их длина меньше 1024 символов:

Псевдонимы полей

Псевдоним поля выборки в запросе указывается после ключевого слова КАК. При этом можно вообще не задавать псевдоним для поля, можно указать после ключевого слова КАК, а можно просто через пробел, без указания ключевого слова КАК:

Псевдоним поля должен удовлетворять правилам наименования переменных в 1С. Например, в псевдониме нельзя использовать пробел, он не может начинаться с цифры и т.п. В рамках одного запроса нельзя использовать одинаковые псевдонимы, иначе будет ошибка «Повторяющийся псевдоним».

В предложении ИЗ указываются таблицы-источники, из которых выполняется выборка. Например, в конфигурации есть справочник «КамерыХранения». Для выборки полей из данного справочника нужно выполнить следующий запрос:

Источник

Типичные причины неоптимальной работы запросов и методы оптимизации

Краткое содержание:

В статье приводятся типичные причины неоптимальной работы запросов, диагностируемые на уровне кода конфигурации, и рассматриваются методики оптимизации запросов.

Значительная часть проблем, приводящих к неоптимальной работе запросов, может быть обнаружена путем анализа кода конфигурации и структуры метаданных. Имеется перечень типичных ошибок в коде и структуре данных, последствия которых достаточно хорошо изучены и легко предсказуемы. Анализ кода с использованием этого перечня позволяет решить большую часть проблем с производительностью запросов, не углубляясь в детальную техническую информацию (текст запроса на языке SQL, план запроса и т.д.).

Основные причины неоптимальной работы запросов, диагностируемые на уровне кода конфигурации и структуры метаданных:

В настоящей статье рассматриваются перечисленные причины неоптимальной работы запросов и даются рекомендации по их оптимизации.

Cоединения с подзапросами

Рекомендации

Если запрос содержит соединения с подзапросами, то это может привести к следующим негативным последствиям:

Пример потенциально опасного запроса, использующего соединение с подзапросом:

Обратите внимание на то, что возможность использования временных таблиц появилась в 1С:Предприятии начиная с версии 8.1. Если вы используете версию 8.0, то для решения проблемы производительности такого запроса следует перейти на 8.1.

Для оптимизации запроса следует разбить его на несколько отдельных запросов (по числу подзапросов, используемых в соединениях). Эти запросы рекомендуется поместить в один пакетный запрос.

Внимание! Не забудьте проиндексировать созданную временную таблицу. В качестве индексных полей следует указать все поля, которые используются в условии соединения.

Для вышеприведенного примера получится следующий пакетный запрос:

Пояснения

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

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

Cоединения с виртуальными таблицами

Рекомендации

Если в запросе используется соединение с виртуальной таблицей языка запросов 1С:Предприятия (например, «РегистрНакопления.Товары.Остатки()») и запрос работает с неудовлетворительной производительностью, то рекомендуется вынести обращение к виртуальной таблице в отдельный запрос с сохранением результатов во временной таблице.

То есть, следует использовать ту же рекомендацию, что и в случае соединения с подзапросом.

Пояснения

Виртуальные таблицы, используемые в языке запросов 1С:Предприятия, могут разворачиваться в подзапросы при трансляции в язык SQL. Это связано с тем, что виртуальная таблица часто (но не всегда) получает данные из нескольких физических таблиц СУБД. Если вы используете соединение с виртуальной таблицей, то на уровне SQL оно может быть в некоторых случаях реализовано, как соединение с подзапросом. В этом случае оптимизатор СУБД может точно так же выбрать неоптимальный план, как при работе с подзапросом, использованным в языке 1С:Предприятия в явном виде.

Несоответствие индексов и условий запроса

Рекомендации

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

Условия используются в следующих секциях запроса:

Для каждого условия должен существовать подходящий индекс. Подходящим является индекс, удовлетворяющий следующим требованиям:

При создании объекта метаданных 1С:Предприятие автоматически создает индексы, которые должны подходить для работы большинства запросов.

Основные идексы, создаваемые 1С:Предприятием:

Детальная информация по индексам, автоматически создаваемым 1С:Предприятием содержится в статье «Индексы таблиц базы данных 1С:Предприятия 8.1».

В тех случаях, когда автоматически созданных индексов недостаточно, можно дополнительно проиндексировать реквизиты объекта метаданных. Информация о том, какие индексы при этом будут созданы, содержится в этой же статье. Следует иметь в виду, что создание индекса ускоряет процесс поиска информации, но может несколько замедлить процесс ее изменения (добавления, редактирования и удаления). Поэтому индексы следует создавать осознанно и только в том случае, если точно известен запрос, для которого такой индекс необходим. Не следует создавать индексы «на всякий случай» или заведомо избыточные индексы. Например никогда не следует дополнительно индексировать первое измерение регистра, поскольку для поиска по значению первого измерения подходит основной индекс таблицы итогов, который автоматически создаст платформа.

Пояснения

Если в структуре базы данных отсутствует индекс, удовлетворяющий всем перечисленным условиям, то для получения результата СУБД будет вынуждена сканировать таблицу или один из ее индексов. Это приведет к увеличению времени выполнения запроса, а так же к возможному снижению параллельности системы, поскольку возрастет количество установленных блокировок.

Примеры

В конфигурации описан регистр накопления ТоварыНаСкладах:

Платформа 1С:Предприятие автоматически создаст для таблицы остатков данного регистра индекс по периоду и всем измерениям в том порядке, в котором они перечислены в конфигураторе.

Рассмотрим несколько примеров запросов и проанализируем, смогут ли они оптимально выполняться при такой структуре данных.

Запрос 1

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

Запрос 2

В данном случае нарушено требование 3. Между измерениями «Склад» и «Качество» в структуре регистра находится измерение «Номенклатура», которое не задано в условии запроса. Этот запрос так же не сможет выполняться оптимально. При его выполнении СУБД выполнит поиск по первому полю индекса, но затем вынужденно просканирует некоторую его часть. Сканирование приведет к увеличению времени выполнения запроса и к блокировке избыточных записей в таблице, то есть к снижению общей пропускной способности системы.

Запрос 3

В этом случае требования соответствия индекса и запроса не нарушены. Данный запрос будет выполнен СУБД оптимальным способом. Обратите внимание на то, что порядок следования условий в запросе не обязан совпадать с порядком следования полей в индексе. Это не является проблемой и будет нормально обработано СУБД.

Использование логического ИЛИ в условиях

Рекомендации

Использование логического ИЛИ в секции ГДЕ запроса

Не следует использовать ИЛИ в секции ГДЕ запроса. Это может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, что увеличит время работы запроса и вероянтность возникновения блокировок. Вместо этого следует разбить один запрос на несколько и объединить результаты.

следует заменить на запрос

Включение пользователей в несколько ролей, каждая из которых имеет RLS

Использование ИЛИ в условиях соединения

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

Использование подзапросов в условии соединения

Рекомендации

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

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

Получение данных через точку от полей составного типа

Рекомендации

Если в запросе используется получение значения через точку от поля составного ссылочного типа, то при выполнении этого запроса будет выполняться соединение со всеми таблицами объектов, входящими в этот составной тип. В результате SQL текст запроса чрезвычайно усложняется, и при его выполнении оптимизатор СУБД может выбрать неоптимальный план. Это может привести к серьезным проблемам производительности и даже к неработоспособности запроса в отдельных случаях.

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

Пример

В данном запросе используется обращение к реквизитам регистратора. Регистратор является полем составного типа, которое может принимать значения ссылки на один из 56 видов документов.

SQL-текст этого запроса будет включать 56 левых соединений с таблицами документов. Это может привести к серьезным проблемам производительности при выполнении запроса. Однако, для решения данной конкретной задачи нет необходимости соединяться со всеми 56 видами документов. Условия запроса таковы, что при его выполнении будут выбраны только движения документов «РеализацияТоваровУслуг» и «ЗаказыПокупателя». В этом случае мы можем значительно ускорить работу запроса, ограничив количество соединений при помощи функции ВЫРАЗИТЬ().

Фильтрация виртуальных таблиц без использования параметров

При использовании виртуальных таблиц в запросах, следует передавать в параметры таблиц все условия, относящиеся к данной виртуальной таблице. Не рекомендуется фильтровать виртуальные таблицы при помощи условий в секции ГДЕ и т.п. Такой запрос будет возвращать правильный (с точки зрения функциональности) результат, но СУБД будет намного сложнее выбрать оптимальный план для его выполнения. В некоторых случаях это может привести к ошибкам оптимизатора СУБД и значительному замедлению работы запроса.

Например, следующий запрос использует секцию ГДЕ запроса для выборки из виртуальной таблицы.

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

Источник