С KR поведение ядра по добавлению хинтов отличается от "чистой" Axapat'ы (без KR)
Без KR добавление ORDER BY не имеет эффекта.
Наличие же INDEX
ВСЕГДА отключает хинты ядра. Причем, даже если самого индекса и не существует в базе (отключен конф. ключ). И здесь так же есть различие в поведении с KR.
Без KR в order by запроса всегда добавляются поля из индекса (для неагрегированного запроса). C KR - только если индекс не отключен в конфигурации.
Так что, с KR можно создать для таблицы фейковый индекс и использовать его для критических запросов
А вообще, выбор того или иного индекса зависит от количества полей, входящих в предложение WHERE, а так же от того, сколько этих полей входит в различные индексы (естественно, если не указывать index hint).
Алгоритм, примерно, следующий:
- Выбирается список индексов, первое поле которых есть в предложении WHERE. Если такой индекс один, то подставляется он в INDEX HINT, если таких индексов несколько - переходим к пункту 2
- Для каждого следующего поля выбранных индексов проверяется, входит ли оно в WHERE. Этот пункт повторяется до тех пор, пока не останется один индекс или не закончится список полей в выбранных индексах. Если остался один индекс, то используется он, если несколько, то отправляется запрос без хинта (пусть сервер сам разбирается)
Для KR наличие order by влияет на хинты, но я не уловил закономерность.
Что заметил - соответствие полей в ORDER BY какому-либо индексу и наличие этих полей в предложении WHERE в некоторых случаях отключает хинты.
PS Я пишу KR, но проверял только на KR2 (dax 3.0 sp5 kr2). Предположение, что это правильно для всех KR - надо проверять
Без KR проверял на Axapta 3.0 sp3 cu1