SAP или 1С?

[Ronin]

В случае селекта из одной таблицы он будет отличаться только большим количеством скобочек. Кстати, индекс, который используется при выполнении вышеприведенных запросов - сложный, который строится по 7ми полям, первые 2 как раз itemID и datePhysical. Возможно именно это объясняет высокую эффективность данного индекса в этом запросе. Впрочем, если Вы получаете иные результаты, интересно было бы посмотреть на запрос, который запускает аксапта с планом и на структуру используемого индекса.

Плохо о ней я начинаю думать при составлении сложных запросов. Там да, она может запрос с outer join представить двумя вложеными запросами типа
while select
{
while select
{
}
}
В свое время меня это очень неприятно удивило.

[Recoilme]

Цитата:

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

В случае селекта из одной таблицы он будет отличаться только большим количеством скобочек.

Не только. Ещё ордер баем будет отличаться. И соответственно - планом.

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

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

[Ronin]

Добрый день, Recoilme!

Не хочу показаться занудным, но отдаю себе отчет в том что данное письмо будет засчитано именно как махровое занудство :-)

Вы писали "хинт заставляет мс скуэль юзать составной индекс итемид/датефизикал на условии датефизикал. В результате разница в быстродействии с Хинтом / без хинта составляет >1,5 часа".

Я же хотел сказать, что само по себе выбор составного индекса не может практически на 2 порядка "тормознуть" выполнение данного запроса. Проиллюстрировал это на примере.
Order by по тому же полю, что и group by в данном случае на выбор оптимизатором индекса не повлияет. Иначе это уже будет огромный камень в огород MS SQL и поводом к выпуску хотфикса, а не генератора запросов Аксапты. На мой взгляд причина описаной вами проблемы лежит в плоскости оптимизации используемой базы данных.

Чтобы не осталось белых пятен, могу сказать, что ваш запрос, запущенный в Job'е из Аксапты отработал не медленнее, чем его аналог в Query Analyzer'e. При этом тестировались 2 разновидности запроса с разными условиями во WHERE:
(Проверка даты) && (Статусы прихода || Статусы расхода)
и ваш запрос
(Проверка даты) && (Статусы прихода) || (Статусы расхода)


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