SAP или 1С?

[Ronin]

Recoilme, чудес не бывает.

Если оптимизатор на таком простом запросе строит план по full scan, такому его решению есть вполне объективные причины. Его искуственный инетеллект не настолько уж и плох. И противопоставлять ему ничего не надо. Наоборот, ему надо помогать всеми возможными средствами

Причин по большому счету может быть 2.
1. Отсутствие эффективного индекса. Вероятность 90%
2. Проблемы со сбором и обновлением статистики. Вероятность в данном случае 9%.
3. Прочий полтергейст. Вероятность не более 1%.

[mifi]

А в чем корень проблемы, удалось установить - в order by или в optionFast?. И если в optionFast - то для всех значений (1,2, 20, 100) или только для определенных?

[Vadik]

Мои пять копеек - (ItemId, DatePhysical, Qty), если забыть про фильтры по StatusReceipt и StatusIssue

Другие (не покрывающие) индексы при таком количестве данных (если мне память не изменяет, порядка 4 миллионов записей в InventTrans на дату) либо не будут использоваться, либо bookmark lookup-ы сделают доступ дороже table scan-а, что собственно и было продемонстрировано выше.

P.S. Забавное обсуждение, особенно если взглянуть на название ветки

[Recoilme]

Действительно. Вот собственно и сравнили SAP с 1Сом

PS: мусолить дальше тему запросов/оптимизаторов/хинтов/индексов - лениво.

[Ronin]

Чтобы закрыть тему индексов окончательно, позвольте поделиться великим и сокровенным знанием о том, чем будет отличаться индекс предложенный Vadik'ом от индекса только по (ItemId, DatePhysical).
Скриншоты с планами запросов я приводить не стану - их можно посмотреть выше.

Интрига вкратце: при использовании очень схожих индексов время выполнения простого запроса отличалось на 2 порядка. Причем объемы таблиц были сопоставимы.

Почему.
Если посмотреть на планы запросов, то можно увидеть следующее - они отличаются не способом поиска записей (что там, что там используется индекс, причем используется по 2м полям ItemId, DatePhysical), а тем как считается сумма.
В быстром случае используется Stream Agregate, в медленном - Bookmark Lookup.
Теперь посмотрим, чем отличаются эти 2 оператора. Для этого воспользуемся хелпом Query Analyzer'a.

The Stream Aggregate physical operator optionally groups by a set of columns and calculates one or more aggregate expressions returned by the query and/or referenced elsewhere within the query. This operator requires that input is ordered by the columns within its groups.

Bookmark Lookup
The Bookmark Lookup logical and physical operator uses a bookmark (row ID or clustering key) to look up the corresponding row in the table or clustered index.

Иными словами, Bookmark Lookup для того чтобы просуммировать поле qty должен "вытащить" из таблицы все найденные записи, чтобы прочитать значение поля. А fetch операция обычно достаточно долгая.

Возникает вопрос, а что Stream Aggregate разве за значением данного поля в таблицу не лезет? В том то и дело, что нет. Для этого опреатора, необходимо чтобы поле, по которому "работает" агрегирующая функция было упорядочено в данной группировке, иными словами, чтобы оно присутствовало в индексе, по которому строился план запроса.

Таким образом...
А что "таким образом"... да собственно ничего. Я хотел сказать, что дальше выводы сделать не трудно.
Вывод 1 - Fetch операция долгая
Вывод 2 - Понимание плана запроса позволяет сохранять нервные клетки
Вывод 3 - Век живи, а все равно всего не изучишь.
Вывод 4 - на усмотрение читателя сего опуса.

[Recoilme]

2 Ronin: Со всем согласен, но думаю топиг нельзя будет считать до конца закрытым не добавив небольшого уточнения.

Здесь на мой непритязательный взгляд достаточно наглядно изложены физические причины торможения такого рода.

Вобщем добавил бы:

Вывод 5: не так страшен натурал как его малюют.

Хотя как говорится на вкус и цвет.

[Recoilme]

Цитата:

Сообщение от dalV

Евросеть одно время состояло а секте суннитов (или шиитов) тех самых у которых принято себя истязать. И использовала эту замечательную программу, которую вы называета одинэс. Странно, что при всем этом богатстве, они перешли на САП.

Где тут конкурс на самый короткий пресс-релиз???
Компания «Евросеть»: «Проводить автоматизацию с помощью SAP R/3 оказалось нецелесообразно»
Блин, пойду Чичваркину письмо писать