SAP или 1С?

[Ronin]

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

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

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

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

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


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