SAP или 1С?

[Ronin]

Здравствуйте, Recoilme!

С нетерпением ждал Вашего ответа. Мое подозрение на счет природы вашей проблемы окрепло. :-)

Насколько я понимаю, индех ItemIdx не изменялся в процессе внедрения? То есть он остался в том виде, в котором создался при инсталляции системы. Если так, то его структура должна быть следующей:
DataAreaID
ItemID
datePhysical.

Теперь, основываясь на имеющихся знаниях, проанализируем ваши запросы и их планы.
select sum(qty), itemID
from inventTrans
where datePhysical<'20041001'
group by itemID
order by itemID

оптимизатор не может найти эффективный индекс для выполнения данного запроса и решает, что раз надо получить все записи, то full scan будет достаточно оптимальным. Использовать индекс ItemIdx он не может по той простой причине, что в запросе отсутствует условие/сортировка/группировка по DataAreaID.

Если мы добавляем в конце опцию FAST 20, оптимизатор решает, что использование хоть какого-то индекса позволит быстрее получить первую партию записей. Напрасно считает :-) Но не его это вина и уж тем более не вина Аксапты. Просто для данного запроса ОТСУТСТВУЕТ эффективный индекс. По факту получается, что самым оптимальным планом является использование Full scan'а.

Что можно сделать.
1. Добавить в инструкцию WHERE фильтр по компании. Или добавить группировку по компании. Плохо, что этот вариант не позволит повысить селективность индекса, но может помочь.
2. Если компания используется одна, то есть смысл вообще убрать из индекса поле DataAreaID.
3. Создать еще один индекс со следующими полями: itemID, datePhysical, и коль мы часто используем в запросе наложения условий по статусам прихода и расхода, то включить в него StatusIssue, StatusReceipt.

При использовании индекса подобного тому, что описан в пп.3, ваш запрос обрабатывался на реальных объемах (15 000 000 записей) 1 минуту и 4 секунды.

Про индексы очень хорошо описано в статье http://www.sql.ru/articles/mssql/03013101Indexes.shtml

Надеюсь мне удалось немного поднять репутацию Аксапты ;-)