В базе около 600 000 тыс. задач, запрос очень тормозит
ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ
    ЗадачаИсполнителя.БизнесПроцесс
ИЗ
    Задача.ЗадачаИсполнителя КАК ЗадачаИсполнителя
ГДЕ
    ЗадачаИсполнителя.ПометкаУдаления = ЛОЖЬ
    И (ЗадачаИсполнителя.Предмет = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет1 = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет2 = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет3 = &Предмет)
    И ЗадачаИсполнителя.БизнесПроцесс.ПометкаУдаления = ЛОЖЬ


Дайте идеи по оптимизации!

ЗадачаИсполнителя.ПометкаУдаления = ЛОЖЬ
два раза зачем? думаешь с одного не поймёт?

а, это на бизнес процесс вторая

вобще не рекомендуется на разные реквизиты ИЛИ условие

1) избавится от неявных вложенных запросов
2) начинать отборы с вложенных запросов, чтобы они собирались уже ограниченные условиями.
3) ПометкаУдаления уже булево, зачем еще раз сравнивать с булевым? пиши просто НЕ ПометкаУдаления.

(2) и с левым соединением

Объединение 4 щапросов будет работать (обычно) быстрее, чем 1 запрос с или
+ есть неявное левое соединение с Бизнес процесс - обращение через 2 точки

(4) про пометку пофиг, в скуле один хрен будет _DeletionMark = 0х00

Реквизиты "ПредметN" проиндексировать

посмотри http://www.youtube.com/watch?v=sCDMemW3zyk
там 5 частей, нормально объяснено

Спасибо!!!

Пробуй ограничить тип БизнесПроцесса, наверняка используется один тип.

ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ
    ВЫРАЗИТЬ(ЗадачаИсполнителя.БизнесПроцесс КАК БизнесПроцесс.ТвойТип) КАК БизнесПроцесс
ИЗ
    Задача.ЗадачаИсполнителя КАК ЗадачаИсполнителя
ГДЕ
    НЕ ЗадачаИсполнителя.ПометкаУдаления
    И (ЗадачаИсполнителя.Предмет = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет1 = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет2 = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет3 = &Предмет)
    И НЕ ВЫРАЗИТЬ(ЗадачаИсполнителя.БизнесПроцесс КАК БизнесПроцесс.ТвойТип).ПометкаУдаления

(0)Замени в ГДЕ кучу ИЛИ одним В СПИСКЕ()

(12) цифры перечисления не справа, а слева.

(0) Вместо ИЛИ сделай ОБЪЕДИНИТЬ ВСЕ из 4-х запросов.

а я думаю дело в "ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ", различные  хорошо утяжеляет запрос, я бы делал запрос напрямую в бизнес процессы и сделал условие с подзапросом. Примерно так (не проверял)
----------------------
ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ЗадачаИсполнителя.БизнесПроцесс
ИЗ
    БизнесПроцессы.БизнесПроцесс КАК БизнесПроцесс
ГДЕ
   БизнесПроцесс.ПометкаУдаления = ЛОЖЬ
  и ЗадачаИсполнителя.БизнесПроцесс в
        (ВЫБРАТЬ РАЗРЕШЕННЫЕ
            ЗадачаИсполнителя.БизнесПроцесс
        ИЗ
            Задача.ЗадачаИсполнителя КАК ЗадачаИсполнителя
        ГДЕ
            ЗадачаИсполнителя.ПометкаУдаления = ЛОЖЬ
            И ЗадачаИсполнителя.Предмет в (&списокПредметов))

чета криво ушло

ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ЗадачаИсполнителя.БизнесПроцесс
ИЗ
    БизнесПроцессы.БизнесПроцесс КАК БизнесПроцесс
ГДЕ
   БизнесПроцесс.ПометкаУдаления = ЛОЖЬ
  и ЗадачаИсполнителя.БизнесПроцесс в
        (ВЫБРАТЬ РАЗРЕШЕННЫЕ
            ЗадачаИсполнителя.БизнесПроцесс
        ИЗ
            Задача.ЗадачаИсполнителя КАК ЗадачаИсполнителя
        ГДЕ
            ЗадачаИсполнителя.ПометкаУдаления = ЛОЖЬ И ЗадачаИсполнителя.Предмет в (&списокПредметов)
        )

опечатался
-------------

ВЫБРАТЬ РАЗРЕШЕННЫЕ
    БизнесПроцессы.БизнесПроцесс
ИЗ
    БизнесПроцессы.БизнесПроцесс КАК БизнесПроцесс
ГДЕ
   БизнесПроцесс.ПометкаУдаления = ЛОЖЬ
  и БизнесПроцессы.БизнесПроцесс в
        (ВЫБРАТЬ РАЗРЕШЕННЫЕ
            ЗадачаИсполнителя.БизнесПроцесс
        ИЗ
            Задача.ЗадачаИсполнителя КАК ЗадачаИсполнителя
        ГДЕ
            ЗадачаИсполнителя.ПометкаУдаления = ЛОЖЬ И ЗадачаИсполнителя.Предмет в (&списокПредметов)
        )

(17) В параметр &списокПредметов передается список реквизитов?

(18) нет, человек не так понял твою задачу, там список значений, а у тебя оно одно

Добавить в Задачу ТЧ "Предметы", переписать их туда.
Написать запрос с учетом этого и вернуться.

(0) у тебя реквизиты: Предмет, Предмет1, Предмет2, Предмет3 индексируются?

(0) По сути это ничто иное как внутреннее соединение - именно так рекомендовалось в одной статье по оптимизации, правда не сильно я заметил в своих задачах прироста скорости выполнения.
Самый производительный способ - это все же через ОБЪЕДИНИТЬ (без ВСЕ), как предложено выше, все-таки различные требуется выбрать. Обязательно сделай то, что предложено в (11).
Про вот это "ЗадачаИсполнителя.ПометкаУдаления = ЛОЖЬ" можно, изуально лучше читается, по производительности в запросе одно и тоже, если будево не сравнивать с булево.
Если кратко:

1. Объединение
2. Внутреннее соединение

Правда, внутреннее соединение следует использовать, если у тебя ПредметN - это одна таблица.

Ах, да --> &Предмет, все-таки одна :)

Всё-таки настоятельно рекомендую избавиться от ИЛИ в условии. И проиндексировать Предметы.

(26) Ребята, вы жгете.

Нууу, в целом, (27) относится ко всем высказавшимся.

(28) А что не так?

(28) Дмитрий, объясни, что-то я не понял.

нормально, всех заинтриговал, а сам ушел, видимо, пиво пить :)

(31) Думаю, он уже того.

Эти 4 реквизита - предмета заменить на ТЧ "Предметы".

И уже потом смотреть, что не так.

(33) с этим все согласятся, что 4 реквизита одного типа - это глупо, но решаем задачу, исходя из первоочередной посылки...аль мне надо сербануть, чтобы тебя понять? :) может, ты другое что имел в виду

(35) "аль мне надо сербануть, ". хмм, гммм, ну пусть будет непереводимой игрой слов белорусского диалекта.

Что касается решения задачи - так вот оно, в (33) решение.

(15) ты пожалуйста больше не пиши такие глупости.

(36) хорошее решение приятное без состояния "а если подумать".

(38) а главное правильное ;) если есть уже 4ри реквизита, кто даст гарантию, что через месяц-два не появится 5ого, а тогда придётся переписывать запрос и скорее всего не один.

(39) а главное осталось понять зачем там 4 предмета

Может уже говорили, но:


ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ
    ЗадачаИсполнителя.БизнесПроцесс
ИЗ
    Задача.ЗадачаИсполнителя КАК ЗадачаИсполнителя
ГДЕ
&Предмет В (ЗадачаИсполнителя.Предмет, ЗадачаИсполнителя.Предмет1, ЗадачаИсполнителя.Предмет2, ЗадачаИсполнителя.Предмет3)
    И ЗадачаИсполнителя.ПометкаУдаления = ЛОЖЬ
    И ЗадачаИсполнителя.БизнесПроцесс.ПометкаУдаления = ЛОЖЬ




"Или" зачастую очень тормозит систему

(41) -> (0)

(41) К сожалению, скорее всего скана таблицы всё равно не избежать при подобном запросе.

В качестве метода научного тыка можно попробовать

ГДЕ НЕ (ЗадачаИсполнителя.ПометкаУдаления И БизнесПроцесс.БизнечПроцесс.ПометкаУдаления)
И ВЫБОР &Предмет
КОГДА ЗадачаИсполнителя.Предмет1 ТОГДА ИСТИНА
КОГДА ЗадачаИсполнителя.Предмет2 ТОГДА ИСТИНА
КОГДА ЗадачаИсполнителя.Предмет3 ТОГДА ИСТИНА
ИНАЧЕ
ЛОЖЬ
КОНЕЦ

Но, вряд ли это поможет. Этот код скорее интересен в части недокументированной возможности использования оператора ВЫБОР.

(41) Тогда уж запрос сделать по-другому, чтобы в скуле был не in, а exists
Решение в 33 хорошее, если это можно сделать.

(0) См. рекомендации (20)(21). Плюс ИЛИ из запроса надо убирать (ОБЪЕДИНИТЬ, либо (16)) - конструкция ИЛИ несмотря на индексы будет сканировать всю таблицу (хотя, возможно, оптимизаторы СКЛ 2012 может и нормально составят план запроса с этим ИЛИ при наличии индексов).

Как минимум, для нормального выполнения "ИЛИ" нужно из запроса выкинуть.

Типичный способ - замена на ОБЪЕДИНИТЬ.

(0) оптимально будет:
1) все реквизиты Предмет* вынести в ТЧ и добавить индексацию по реквизиту
2) Сделать пакетный запрос, примерный:

ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ
    ЗадачаИсполнителяПредметы.Ссылка КАК Ссылка
ПОМЕСТИТЬ ПредметыТЧ
ИЗ
    ЗадачаИсполнителяПредметы КАК ЗадачаИсполнителяПредметы
ГДЕ
    ЗадачаИсполнителяПредметы.Предмет В(&Предмет)

ИНДЕКСИРОВАТЬ ПО
    Ссылка
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ЗадачаИсполнителя.БизнесПроцесс КАК БизнесПроцесс
ПОМЕСТИТЬ ЗадачиИБП
ИЗ
    ЗадачаИсполнителя КАК ЗадачаИсполнителя
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ПредметыТЧ КАК ПредметыТЧ
        ПО ЗадачаИсполнителя.Ссылка = ПредметыТЧ.Ссылка
            И (НЕ ЗадачаИсполнителя.ПометкаУдаления)

ИНДЕКСИРОВАТЬ ПО
    БизнесПроцесс
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ
    БП.Ссылка
ИЗ
    ЗадачиИБП КАК ЗадачиИБП
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ НужныйБизнесПроцесс КАК БП
        ПО ЗадачиИБП.БизнесПроцесс = БП.Ссылка
            И (НЕ БП.ПометкаУдаления)


(0) А почему в базе предмет не ТЧ? Если вынести в ТЧ Предметы, ИМХО, очень эффективно избавит от ИЛИ в запросе.

Типичные причины неоптимальной работы запросов и методы оптимизации
использование логического ИЛИ в условиях;
http://myfolder.ru/files/41911355

1. Попробуй без РАЗРЕШЕННЫЕ. Если запрос значительно ускорится, то смотри в техножурнале конечный запрос к СУБД на предмет отягощения его запросами RLS.
2. Если поля ПредметX многотипные, попробуй наложить отбор по типу значения поля (ЗадачаИсполнителяПредметы.ПредметX ССЫЛКА <ТипМетаданных>.<ОбъектМетаданных>)
3. Думаю временные таблицы здесь врядли дадут заметный выигрыш. Пробуй их в последнюю очередь.

(51) Тип поля "ПредметХ" тут не влияет. Влияло бы, если бы сравнение было не на эквивалентность, а на вхождение.

Мы идем в тишине по убитой весне,
По разбитым домам, по седым головам,
По зелёной земле, почерневшей траве,
По упавшим телам, по великим делам...

Ворох писем....


Это я к чему? Автор забыл уж о своих ветках и проблемах.

:)

(52) Согласен. Однако тут многие уже прописывали замену одним полем и соответственно условием "В". Кроме того возможно исходное условие

И (ЗадачаИсполнителя.Предмет = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет1 = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет2 = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет3 = &Предмет)

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

И ЗадачаИсполнителяПредметы.ПредметX ССЫЛКА <ТипМетаданных>.<ОбъектМетаданных1>
И ЗадачаИсполнителяПредметы.ПредметX ССЫЛКА <ТипМетаданных>.<ОбъектМетаданных2>
И ЗадачаИсполнителяПредметы.ПредметX ССЫЛКА <ТипМетаданных>.<ОбъектМетаданных3>
И (ЗадачаИсполнителя.Предмет = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет1 = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет2 = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет3 = &Предмет)

(55) Не согласен с последним утверждением, что допустимо заменить - результат не идентичен запросу из (0) т.к. нам нужно, чтобы хотя бы один из ПредметХ был нужного типа и значения, у вас же накладываются ограничения по типу и на остальные поля ПредметХ, таким образом, могут быть пропущены данные, когда Предмет1 = &Предмет, а Предмет2, допустим, совсем левый (другая Tref, число, дата  и т.д.).

Согласен, что заигрывания с приведением типов могут в таких сложных случаях как-то повлиять и субд будет использовать предикаты по составному индексу для поля (тип составного типа, тип метаданных, ссылка). Но в лучшем случае это будет 4 выполнения index seek, если для каждого из полей Предмет создан свой отдельный индекс и эти значения достаточно селективны. Скорее всего, тут вообще индексов даже нет по этим полям...

(56) И 4 index seek по разным идексам, как я понимаю, возможны только при 4 объединениях, а из 1го запроса этого не достичь. Но могу ошибаться...

() ...Про предложение "объединить все" вместо "ИЛИ"...
Думаете 4 полных цикла отработают быстрее чем один с четырмя проверками? Безумству храбрых пою я песню (с)

(0) Скорее всего мучают различные.

Сначала выбери все разрешенные, а потом мучай различные.
//Например:

ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ЗадачаИсполнителя.БизнесПроцесс
ПОМЕСТИТЬ УраОтобрали
ИЗ
    Задача.ЗадачаИсполнителя КАК ЗадачаИсполнителя
ГДЕ
    ЗадачаИсполнителя.ПометкаУдаления = ЛОЖЬ
    И (ЗадачаИсполнителя.Предмет = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет1 = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет2 = &Предмет
            ИЛИ ЗадачаИсполнителя.Предмет3 = &Предмет)
    И ЗадачаИсполнителя.БизнесПроцесс.ПометкаУдаления = ЛОЖЬ
;
ВЫБРАТЬ РАЗЛИЧНЫЕ
БизнесПроцесс
ИЗ
УраОтобрали.

(0) Индексы по предметам нельщя создать как нибудь?

(58) Если есть 4 индекса, то будет не 4 полных цикла.

(56) Я написал _возможно_..._допустимо_заменить, т.е. предполагал, что существует вероятность наличия не озвученных автором условий. Это не было безусловным утверждением.

(60) Четыре полных. Идти будут быстрее по индексированным полям.

(60) (62) вот вы жгете, что есть "четыре полных неполных цикла" ?
(62)  >>Идти будут быстрее по индексированным полям.
имхо, заблуждение

(62) Ты, очевидно, ни малейшего представления о физических операторах СУБД не имеешь. Зачем пишешь тогда всё это? Непонятно. Выглядишь глупо.