Добрый день!

Насколько известно, например из статьи http://kb.1c.ru/articleView.jsp?id=44#or , наличие логического оператора "ИЛИ" в "ГДЕ" и в условии соединения может приводить к фуллскану.

Но вот есть пара вопросов:
   1. можно ли где-нибудь найти дополнительные критерии, возникновения этого;
   2. помогает ли замена ИЛИ на конструкцию ВЫБОР избежать этого? Например, конструкцию вида "Поле1 = 1 ИЛИ Поле1 = 2" заменить на "ВЫБОР КОГДА Поле1 = 1 ТОГДА ИСТИНА КОГДА Поле1 = 2 ТОГДА ИСТИНА ИНАЧЕ ЛОЖЬ"

1. почему может, а не всегда приводит?
2. не помогает

case еще более усугубит ситуацию

помогает "объединить все"

(1) Таки всегда? Или бывают ситуации, когда это безобидно.

(3) Но не в ДС :(

(4) что есть ДС?

(5) демонический список

(6) тогда накуй он нужен такой ))

(7) Да, не, штука хорошая, но вот все эти ограничения делают ее слишком уж узкоспециализированной.

Интересно, а в случае опционального фильтра тоже "ИЛИ" провоцирует фуллскан?

Например,
ГДЕ
  &БезФильтра ИЛИ Таб.Поле1 = &ЗначениеФильтра

?

На самом деле там не все так очевидно, мс скул, умный, он может и сам разрулить "или" если будет возможность, пробовал, зачастую оптимизатор строит нормальный план. Но вот гарантировать этого нельзя.

Если "или" по одному полю, то не так уж все печально.
Если поле попало в индекс, то как правило Index Seek ... Where.

(10) Как я понимаю, вероятность выше в простых случаях?

Сейчас в Динамическом списке заменил ИЛИ в условие соединения на подзапрос с объединением (что тоже не особо радует) и получил прирост в скорости в 2-3 раза.

(11) В (12) был случай как раз с одним полем:

ПО Таб.Поле1 = &Парам1 ИЛИ Таб.Поле1 = &Парам2

Не верьте всему, что пишут на заборе всякие Ненавижу.

Если будет 2 индексированных поля и по ним будет ИЛИ - будет 2 IndexScan

(9) Будет IndexScan, все норм.

работа оптимизатора запроса зависит от версии мс скуля? (ну там обычный или энтерпрайз)?

Блин, пардон,
IndexScan читать как IndexSeek

(16) Нет.

(16) работа оптимизатора запроса зависит от версии сервера 1С

(14) По двум полям-то скорее всего, а вот по одному полю скорее всего index seek.
(13) В условиях соединения не проверял, смотрел план для where.

К примеру

ВЫБРАТЬ
   Номенклатура.код
ИЗ
   Справочник.Номенклатура КАК Номенклатура
ГДЕ
    Номенклатура.код = &код или
    Номенклатура.Артикул = &Артикул

вызовет 2 IndexSeek по индексам с Кодом и Артикулом, потом MergeJoin, а, затем, как ни прискорбно, KeyLookup, ну а что поделать. Но KeyLookup - это мелочи.

(14) хз конечно, но когда я писал про
А=Б ИЛИ (А ЕСТЬ NULL И Б ЕСТЬ NULL)
мне сказали, что индексам хана

(20) IndexSeek везде, я опечатался.

(19) не, я именно скуль имел ввиду. Слышал, что скорость коррелированных подзапросов как раз зависит от версии

(23) Если для этих полей есть отдельные индексы, то да.

(21) А вот если 2 поля, и одно - неиндексное - тогда table(clasteredIndex)Scan, без вариантов. Ибо проще один раз табличку посмотреть, чем сначало в индексе шариться, а потом опять таки табличку смотреть.

(25) А если - один?

(21) В этом варианте в ИЛИ разные поля, а если будет:

ВЫБРАТЬ
   Номенклатура.код
ИЗ
   Справочник.Номенклатура КАК Номенклатура
ГДЕ
    Номенклатура.Артикул = &Артикул_1 или
    Номенклатура.Артикул = &Артикул_2

В этом случае как будет?

(28) IndexSeek + LookUp

Норм.

ИЛИ по идексироему полю нормально отрабатывает

(30) см (26)

(31) по неидексируемым полям ваще без разницы как отбор накладывать.
Хуже уже не будет )))

(27) А если один индекс в котором оба поля, то одно из полей по или точно не попадет в индекс.

(29) Тогда почему такие рекомендации в  http://kb.1c.ru/articleView.jsp?id=44#or ? Излишняя осторожность?

(33) Да, IndexScan.
Это печально.

(34) Access Denied

(32) Ну почему же.
Есть же
И

ВЫБРАТЬ
   Номенклатура.Наименование
ИЗ
   Справочник.Номенклатура КАК Номенклатура
ГДЕ
    Номенклатура.код = &код и
    Номенклатура.Весовой = Истина


IndexSeek+KeyLookup

Отлично все.

(37) отбор по неиндексируемым полям - это всегда тайбл скан

(38) код - индексируемое поле

(40) Я об этом раньше сказал.

Короче, речь о том, что
Индексное и Неиндескное поле
IndexSeek+Lookup при И
TableScan при ИЛИ

Оба Индексных
2 IndexSeek полюбому

Индексное поле и Константа
IndexSeek

Несколько условий на индексное поле
IndexSeek

Общий индекс на 2 поля:
IndexScan  (это я пока не осмыслил)

(36) Цитирую сюда:

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

Например, запрос

 

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001" ИЛИ Артикул = "002"
 

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

 

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001"
|ОБЪЕДИНИТЬ ВСЕ
|ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "002"

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

"

(42)
Общий индекс на 2 поля:
IndexScan  (это я пока не осмыслил)

Тут все просто. Вот структура индекса

"Поле1,Поле2" рассматривай "или" как два отдельных условия.
В первом случае условие по Поле1 попадет в индекс, так как это поле первое в индексе.
А вот отдельное условие по Поле2 не попадет, так как оно второе, а для поля1 значения нет.

(43) для мс скл -  пох

(43) Тут ключева фраза "Это может привести к тому, что СУБД не сможет использовать индексы таблиц". Слово "может привести", а может и не привести.

(46) Вот именно этот момент и озадачил при прочтении :)

(44) Тоесть, СоставнойИндекс по 2-м полям нужен только для оператора
И
?

(48) конечно

(49) Зато... Зато...
Зато я на велике быстрее гоняю!

Хм ... любопытно все это :) Надо, в  общем, добраться уже до скуля и смотреть, что там из 1Сных вопросов получается в конкретном случае, а не избегать ИЛИ как огня ...

(46) > Это может привести к тому, что СУБД не сможет использовать индексы таблиц

Какие ваши доказательства?

+(52) > Это может привести к тому, что СУБД ...

А может и не привести?

(53) 1с не предоставляет доказательств

(54) мне очень нравится сочетание "это может привести к тому..."

Жизнеутверждающе. Пойдешь в лес - волк может сожрать, а может и не сожрать :)

(54) Дык ,получается, неопределнность возникает на уровне 1С или SQL? Или на данный момент никакой неопределнности нет уже на 100%.

(56) Все определено.

(52) Я просто привел цитату из рекомендации (43) , это не мое утверждение. А то что может привести или не привести, это выше обсуждалось.

> что увеличит время работы запроса и вероянтность возникновения блокировок.

С каких пор грязное чтение вызывает блокировку?

(56) На сторное SQL, так как план запроса, то есть как получить данные, описанные в запросе решает планировщик скуля, причем на основании достаточно большого количества факторов.

Пути SQL часто неисповедимы.

Долго ломал голову, но так и не победил простейший запрос:
ВЫБРАТЬ ...
ИЗ
   РегистрСведений.ЦеныНоменклатурыПоКлиентам КАК ЦеныНоменклатурыПоКлиентам
ГДЕ
   Период <= &Дата
   И ДатаОкончания >= &Дата
   И Контрагент = &Контрагент
И Активность

Строчка "И Активность " - приводит к тормозам, но не всегда, зависит это от погоды на Луне и вспышек на Солнце.
Ну и от обновления статистики тоже зависит :) Как обновишь, так появляются тормоза, переставляешь условия местами - всё работает быстро до следующего обновления статистики.

Выкинул это условие в итоге от греха подальше.

(61) работай со срезом, строчка "И Активность" не понадобится

(55) Именно так. Причем сам запрос может не меняться, но от входных параметров может меняться план запроса, и скуль уходит в даун.

(63) Отличная отмазка.

(64) Т.е. вы на 100% уверены в правильности своего мнения?

Хм, надо бы помоделировать разные ситуации.

(65) это может привести к тому, что клавиатура поломается

(64) Если бы это не было правда. Сам нарывался. Правда на прямых запросах к семерке. Когда ставишь период отчета чуть больше, и скуль уходит в кросс джойн, хотя в самом запросе им и не пахнет.
Там правда слегка кривоватые соединения были, но факт есть.
Переписал с использованием временных таблиц, все стало стабильно предсказуемым.

(65) Нет.
Это я к тому, что в дофига случаев граждане товарищи отнекиваются от разбора полетов и звучит фраза:

"SQL выбрал неправильный план запроса, с кем не бывает".

Ладно там чьято левая база, но скорее всего даже в своей базе не будут ковырять.

(67) может просто кривой запрос был?

(66) Это может привести к тому, что Пират покинет эту ветку по причине флуда и отсутствия фраз по делу.

(68) Ну это да, железная отмазка :). Но при желании все можно разрулить :).

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

(62) Там такой размер регистра, что от среза как раз пришлось отказаться :)

(72) 95% случаев тормозов в моей практике - это ошибки в 1С коде (ДокументВыборка, Обращение через точку (в цикле), Ссылка.Ссылка в Запросе) Это находится на 1-2-3 ЗамеромПроизводительности.

(74) В 1С-ном коде это действительно все просто отыскивается. А вот отладка запроса задача, согласитесь, нетривиальная. Оценить код самого запроса на стороне 1С порой недостаточно.

(69) Я и не спорю что кривой. Но факт остается. Абсолютно один и тот же запрос при разных параметрах выполнялся на склуе по разному, именно план запроса строился другой.

Вернемся к старым песням....

Вот у меня есть условие мощное, которое по идее должно сводиться к ClusteredIndexSeek и KeyLookup на большую таблицу, а оно сводиться к кривому плану запроса, в котором тока ClusteredIndexSeek с Warning-ом
"Columns with no statistics"

Вот така фигня, малята.

Вот запрос:

ВЫБРАТЬ
   Движения.СерияНоменклатуры,
   Движения.Номенклатура,
   Движения.Количество
ПОМЕСТИТЬ ДвиженияОбщие
ИЗ
   РегистрНакопления.ТоварыОрганизаций КАК Движения
ГДЕ
   Движения.Период МЕЖДУ &НачалоПериода И &КонецПериода
   И Движения.Организация = &Организация
   И Движения.Активность = ИСТИНА
   И (Движения.Номенклатура, Движения.СерияНоменклатуры) В
           (ВЫБРАТЬ
               НоменклатураИСерия.Номенклатура,
               НоменклатураИСерия.СерияНоменклатуры
           ИЗ
               НоменклатураИСерия КАК НоменклатураИСерия)

Когда я оставляю только

ГДЕ
   Движения.Период МЕЖДУ &НачалоПериода И &КонецПериода
   И Движения.Организация = &Организация
   И Движения.Активность = ИСТИНА

тогда - норм, ClusteredIndexSeek

Вот это я понимаю, SQL построил кривой план запроса, с пояснениями, так сказать :-)

(77) Ненене, KeyLookup не должно быть, это же Clustered!

Понапридумывали технологий, блин.

Warning
"Columns with no statistics" - насколько серьезно?

А НоменклатураИСерия это что за таблица ?

Columns with no statistics это нету статистики, а потому скль в ступоре как делать, ну и делает слегка пальцем в небо.

(82) Временная таблица, предварительно отобранная.

Может тогда есть смысл проиндексировать ее и внутренним соединением заменить

И (Движения.Номенклатура, Движения.СерияНоменклатуры) В
           (ВЫБРАТЬ
               НоменклатураИСерия.Номенклатура,
               НоменклатураИСерия.СерияНоменклатуры
           ИЗ
               НоменклатураИСерия КАК НоменклатураИСерия)

(83) Обновлял статистику по табличке с Fullscan тока что - бесполезно.
Там уже есть созданная статистика для тех же колонок, что в кластерном индексе.

(85) Счаст попробую.

(85)+ А то это у тебя опять "или" по разным поля, еще и "В". Если еще и НоменклатураИСерия с приличным количеством элементов, то не айс.

(88) Нет у меня там ИЛИ

(88) ВнутреннееСоединение помогло.

(90) Без индексации ВТ

Я в шоке.

Хотя насчет "или" это я может и погрячился. Не свосем догоняю как это "В" выполнится на скуле.

Вот он пример неопределенности Гейзенберга... :-)

(92) Ну а че "В" в ГДЕ вполне себе можно представить как перебор с условием в цикле, образно говоря.

(95) И? Причем тут тогда этот Warning ?

(96) Это у скуля надо спросить :). А в "Или" вполне могло развернуться вот это

(Движения.Номенклатура, Движения.СерияНоменклатуры) В

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

(97) Если есть возможность глянь скулевый запрос, получившийся с
(Движения.Номенклатура, Движения.СерияНоменклатуры) В

(98) вот это условие в sql

AND EXISTS(SELECT
1
FROM #tt2 T2 WITH(NOLOCK)
WHERE (T1._Fld18873RRef = T2._Q_001_F_000RRef) AND (T1._Fld18875RRef = T2._Q_001_F_001RRef))

как выразился Fragster , это "связанный подзапрос" (вроде так), но он не может подойти к аппарату, он на Нимфостарте...

Походу SQL не может его переварить нормально.

А сервак у нас на 8.2.17, а 1С вроде обещала в 8.2.18 что то исправить в операторе
В

(99) А, коррелированный подзапрос, или связанный. Ну таки да, тормознутый он. Как раз к нему и подходит сравнение с запросом в цикле.

А попробуй еще разбить, ради эксперимента,

И (Движения.Номенклатура, Движения.СерияНоменклатуры) В
           (ВЫБРАТЬ
               НоменклатураИСерия.Номенклатура,
               НоменклатураИСерия.СерияНоменклатуры
           ИЗ
               НоменклатураИСерия КАК НоменклатураИСерия)

на

И (Движения.Номенклатура В
           (ВЫБРАТЬ
               НоменклатураИСерия.Номенклатура
           ИЗ
               НоменклатураИСерия КАК НоменклатураИСерия))
И ( Движения.СерияНоменклатуры В
           (ВЫБРАТЬ
               НоменклатураИСерия.СерияНоменклатуры
           ИЗ
               НоменклатураИСерия КАК НоменклатураИСерия))

и посмотри как он его в скуль переварит.

(103) переварил норм.

AND T1._Fld18873RRef IN
(SELECT
T2._Q_001_F_000RRef AS Q_002_F_000RRef
FROM #tt4 T2 WITH(NOLOCK)) AND T1._Fld18875RRef IN
(SELECT
T3._Q_001_F_001RRef AS Q_003_F_000RRef
FROM #tt4 T3 WITH(NOLOCK))

Но warning остался.

А по скорости как ? А warning это наверное к временной таблице, по ней наверное статистику не строит.

(105) Ненене, статистики нет по регистратору в кластерном индексе.

По времени - никак, не перезапущу я счаст боевой SQL

(107) Понятно, спасибо.