Запрос по документам, условия по нескольким полям и по Проведен.

Имеет ли смысл поиграться порядком условий в запросе для оптимизации оного? Или парсер запроса сам всё отработает?

(0) условия вычисляются в том порядке, в котором они написаны. Имеет смысл

вперёд по Проведён, потом остальное

Еще важно чтобы они в одну строку были, выигрыш 5%

(2) Обоснуй.

запрос с фильтром только по дате работает быстрее чем с фильтром по дате и проведен

чтоб у непрведенных реквизиты не проверять сразу.
Что логичней и быстрей? "Проверяем реквизиты и если проведён то норм" или "если проведён то проверяем реквизиты". я правда ХЗ такая логика в языке запросов работает или нет.

На самом деле большинство документов в базе проведённые, поэтому условие по "Проведён" можно смело ставить на последнее место.
(6) В базе 1000 документов, 500 по 1 организации и 500 по второй . 999 проведено и 1 не проведён. Да мне пофигу отберёт запрос сначала 999 документов или 1000. А вот если первым я поставлю условие по "Организации", тогда второе условие будет проверятся уже только у половины документов.

(2) классики говорят ставить первым то условие, которое вернет минимум документов, поэтому условие на Проведен последним хочется.

тут на статистику документооборота смотреть надо.
и ставить в начало те условия, которые будут отсеивать максимальное количество строк

(7) от реквизитов зависит и от проведённх. если там 999 непроведено? а вобще - не то место это где за производительность надо бороться имхо

(8) согласен

(11) Ну дык, я те то же самое написал.

(5) это вранье. Только что проверил

(1) пруфссылку

(12) ну дык, вечер уже:)

(14)+100500, причем на разных СУБД ;)

(13) тогда смысла в сабже нет, если 2 условия выполняются столько-же времени что и одно

(14), (16) зануды

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

(13) Криво проверял значит. По дате есть индекс, а по полю проведен нет

(17) два условия выполняются быстрее, чем одно

(19) Где написано????

(20) нормально проверял - с разными значениями Проведен. И так, и эдак быстрее работает два условия

(23) На файловой наверно проверял

(24) да вообще-то на серверной, у которой файл данных весит 2.7Тб

(24) может это просто ты чо-то не то делал, когда получил обратные результаты?

(22) да, в СП нет, видимо в книжке какой-то читал)

(26) Если выборка одинаковая получается, а диапазон отбора маленький (чтоб впо инденксу искалось, а не сканом таблицы) то никак не может 2 операци выполняться быстрее одной

(28) две выполняются не всегда, потому, что в запросе сокращенное вычисление условий. Именно по этому верно утверждение (1)

База серверная, MSSQL, будут проверки по полям "Организация" и "ДокументОсенование". Потом будут вычисления по табличным частям.

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

P.S. (19), что есть СП?

(29) Ты представляешь как сиквел вычисляет условия???

(29) А хоть раз план завпроса выводил?

(0) не имеет смысла. порядок вычисления выбирает оптимизатор

Ну вот... пришёл лесник и всех разогнал :-)

(33) А чего же тогда этот твой чудо оптимизатор не может с порядком условий в виртуальных таблицах справится?
З.Ы. Я лично в своей базе ускорил проведение документа в 30-60 раз, просто поменяв в регистре накопления порядок измерений (просто мне лень было лазить по всей конфе и менять запросы которые авнокодеры одинэсовские наваяли).

пруф

http://technet.microsoft.com/ru-ru/library/ms173545.aspx

в самом низу, Замечания

(35) на (35) ответь.

(33) так оптимизатор-то тоже не дурак. Более того, он местами умнее некоторых адинэсников

(31) выводил, только не ради условий. У меня доступа нет в сиквелу, прямо сейчас посмотреть не могу, но вот такой запрос:

"ВЫБРАТЬ
   ЗаказПоставщику.Ссылка КАК Ссылка,
   ЗаказПоставщику.Представление КАК СсылкаПредставление,
   ЗаказПоставщику.Дата КАК Дата1
ИЗ
   Документ.ЗаказПоставщику КАК ЗаказПоставщику
ГДЕ
   ЗаказПоставщику.Дата = &П
   И ЗаказПоставщику.Проведен = &П2"                                                            

выполняется не дольше, чем такой же, но без второго условия.
Непроведенных документов существенно больше проведенных в этой базе, по этому запрос с параметром П2=ложь отрабатывает иногда так же, как запрос вообще без этого условия, но чаще на 0.012сек быстрее (в базе 400+ пользюков, видать блокировки мешают). Вариант с П2=истина в три раза быстрее отрабатывает, чем без второго условия.

(35) а это здесь совсем не причем. в твоем случае я так понимаю индексы причем

(39) Как это не при чем? Есть запрос к виртуальной таблице регистра. В нём несколько условий. Меняем местами порядок условий, запрос отрабатывает в десять раз быстрее. Как так? (Я не стал менять запросы, а поменял порядок измерений в регистре, результат тот же).

(40) берешь планы обоих запросов и смотришь. будет видно почему так. в общем случае скуль не гарантирует порядок вычисления условий.

(40) порядок измерений <> порядок условий в запросе, и таки да, действительно влияет на скорость, если по измерениям установлены индексы

(1) Кстати, если отбор по "Проведён = ИСТИНА", то не лучше ли запрос к регистру какому нибудь сделать?

(0) Сделай себе правильных индексов и пользуй их - будет максимальная скорость :)
Оптимизатор подстроится под индекс если такой найдется.
Первый вызов может быть не быстрым (строится план и проводится оптимизация, данные кэшируются) зато последующие могут дать прирост в скорости :)