Если мне не изменяет память, статистика автоматически строится только по первому полю индекса, каковым в случает Аксапты всегда является поле dataAreaId. Кроме того, если при выполнении запроса системе не хватает данных о распределении значений в поле, то она также пытается построить статистику по этому полю. Правда тут есть некая заковыка: Если система считает что строить статистику на лету слишком долго (ну типа - пока еще 17 миллионов записей обработаешь), то она эту статистику просто не строит, а работает на некоторых умолчаниях (например что для полей типа дата все выборки за данными старше одной недели делать full scan
) Так что есть очень большое подозрение, что в вашем случае нужной статистики просто нету.
Поэтому - есть один очень простой рецепт борьбы с некорректными планами запроса. Если план запроса получается странноватым, то прежде всего нужно ручками СОЗДАТЬ статистику по тем полям, которые используются для range или join. Обновление статистики не дает нужного эффекта, поскольку оно обновляет уже СУЩЕСТВУЮЩУЮ статистику. Если система так ни разу и не собралась с мыслями эту статистику по полю создать, то и обновление не поможет.
Если и после этого план получается странным - надо проверить что в нужных местах стоит режим forceliterals, потому что без него оптимизатор просто игнорирует статистику. Правда, в нашем случае он наверняка стоит, поскольку в обратном случае система делала бы одинаковый план запроса для любой даты.
Если после всех этих простых действий система продолжает генерировать кривой план запроса - вот тут уже можно заниматься всякими шаманскими действиями типа построения кластерного индекса по recId и тп.
Кстати - еще очень рекомендую в MS SQL 2005 в свойствах БД ставить галочку "Auto update statistics asynchronously". Ее смысл состоит в том что если даже система решила сэкономить время и выполнять запрос на умолчаниях (то есть без ожидания построения статистики), то статистика по данному полю все равно потихоньку собирается, на случай если она пригодится для следующих запросов.
Правда - в вашей ситуации я бы все равно начал с ручного создания статистики - чтобы по крайней мере понять в чем дело - в кривой статистике или в некорректной работе оптимизатора запросов. Галочку поставить тоже стоит, но немедленного эффекта она не даст. Просто спустя какое-то время выяснится что система набрала нужный объем статистик и стала реже врать в планах запроса.
В конце-концов, если в ручную созданная статистика не помогла, ее удалить не долго. Но по крайней мере можно будет быть увереным что это именно глюк оптимизатора и мы, так сказать, имеем полное моральное право заниматься грязными программистскими трюками для преодоления его последствий.