[SHiSHok]

Почемуто я считал что:
INDEX - жесткое указание использовать индекс, а
INDEX HINT - подсказка оптимизатору (но он может и проигнорировать)
В старой доке как то расплывчато написано:
Index or Index Hint keywords
This keyword can be used either in the form “INDEX indexName” or “INDEX HINT indexName”. If the keyword HINT is not given an order by the index components is sent to the SQL server as minimum. The kernel automatically tries to determine which index is the obvious choice for a given statement and inserts an appropriate index hint.

Сегодня, после долгих тестов и изучения уже "свежего" трактата (AX-300-TIP-024-v01.00-ENUS.doc),:
Index or Index Hint keywords
This keyword can be used either in the form “INDEX indexName” or “INDEX HINT indexName”. If the keyword HINT is not given, Axapta will generate an order by corresponding to the index components.
As a “wrong” index hint can have a big performance impact, Index hints should only be applied to SQL statements that do not have dynamic where clauses or order by’s and where the effect of the hint can be verified.
Axapta will automatically remove index hints referring to a disabled index.
все стало на свои места.

У Вадика тест хороший, но озвучу важные для меня моменты и дополню:
INDEX разворачивается Axapta в предложение ORDER BY <список полей индекса>, без хинта INDEX в SQL запросе (в первой версии доки сказано, но очень непонятно, в "свежей" версии сказано лучше: generate an order by).
INDEX HINT жестко, как я понял, прописывает в запросе сиквелу хинт INDEX во всех случаях, кроме случая когда в условии отбора записей WHERE указан список полей Primary Index-а таблицы, т.е.

Немного модифицировав пример Вадима имеем таблицу HintTable с
полями: value, value1, recId;
индексами: IX_value[value], IX_value1[value1], RecId[RecId]
Индекс RecId кластерный и primary.

и запрос:

select t index hint IX_Value where t.value1 == int2str(rand.nextInt());

транслируется сиквелу:
SELECT A.VALUE,A.VALUE1,A.RECID
FROM HINTTABLE A(INDEX(I_50029IX_VALUE))
WHERE ((DATAAREAID=@P1) AND (VALUE1=@P2))
OPTION(FAST 20)

запрос (явно указываем совершенно ненужный индекс):

select t index hint IX_Value where t.recId == rand.nextInt();

транслируется сиквелу с перебивкой индексного хинта (аксапта подставляет PrimaryIndex по полям которго идет отбор записей):
SELECT A.VALUE,A.VALUE1,A.RECID
FROM HINTTABLE A(INDEX(I_50029RECID))
WHERE ((DATAAREAID=@P1) AND (RECID=@P2))
OPTION(FAST 2)

но если в where избыточное, по сравнению с полями в PrimaryIndex, количество полей в условии WHERE то запрос вида:

select t index hint IX_Value where t.recId == rand.nextInt() && t.value1 == int2str(rand.nextInt());

транслируется с явно указанным хинтом, хотя индекс совершенно "левый" и явно ухудшает стратегию выполнения запроса. Но primary index уже небыл подставлен (логично в принципе).
SELECT A.VALUE,A.VALUE1,A.RECID
FROM HINTTABLE A(INDEX(I_50029IX_VALUE))
WHERE ((DATAAREAID=@P1) AND ((RECID=@P2) AND (VALUE1=@P3)))
OPTION(FAST 20)


Это единственный случай, который я обнаружил, когда Axapta делает перебивку хинта.
Надеюсь информация будет полезна.