как указать сиквелу hint INDEX

[SHiSHok]

собствено говоря : как сказать аксапте передать сиквелу hint INDEX ?
я думал что знаю (некоторые таже могут считать что это выражение x++ index), но ошибался.

[ice]

select Table index hint TableIdx

разве не то?

[mazzy]

Цитата:

Сообщение от SHiSHok

некоторые таже могут считать что это выражение x++ index.

А некоторые нашли и выражение index hint

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

Спросите зачем?
Поищите, здесь много обсуждений было с этими ключевыми словами.
Начните, например, отсюда
http://www.axapta.mazzy.ru/lib/querytuning/
http://www.axapta.mazzy.ru/lib/indexhints/

[fomenka]

Из руководства разработчика

Цитата:

Index hint
Gives the database a hint to use this index to sort the selected records as defined by the index. The database may choose to ignore the hint.

Вас смущает, что БД может проигнорировать hint? Так он на то и hint.

[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 делает перебивку хинта.
Надеюсь информация будет полезна.

[Vadik]

как уже указали, разница index и Index hint четко сформулирована в руководстве разработчика

Цитата:

index
Instructs the database to sort the selected records as defined by the index.

Index hint
Gives the database a hint to use this index to sort the selected records as defined by the index. The database may choose to ignore the hint.

описанное в примере поведение - "фича" последних версий
см. "кто использует KR3?"

P.S. Вообще о таких фичах вендору предупреждать не помешало бы, а так же не включать их по умолчанию и не превращать процесс их отключения в увлекательный квест. Но "жираф большой, ему видней"..

[SHiSHok]

примечание: тестировалось на Ax3.0sp3 vs SQL2k sp3

[SHiSHok]

и совсем забыл сказать где началась у меня путаница: в Axapte мониторил запрос просматривая План исполнения запроса из Axapta. Так вот Axapta для запроса с хинтом INDEX (не INDEX HINT) в плане исполнения запроса мне показывала что индекс таки используется, но НИ в запросе пришедшем на сиквел, НИ в плане его исполнения я так и не увидел чтоб индекс использовался.

Т.о. есть темное пятно в работе формы SysTraceExecPlan : почему там отображается один план, а сиквел строит другой?

[Logger]

Цитата:

Сообщение от SHiSHok

Т.о. есть темное пятно в работе формы SysTraceExecPlan : почему там отображается один план, а сиквел строит другой?

Может быть проблема с кешированием планов исполнения ?
Попробуйте кеши сервера базы данных поубивать и после этого опять посомтреть план запроса. по идее одинаковый должен быть.

[SHiSHok]

кеширование , к сожалению, здесь ни при чем и как мне подсказывали Prepared Execution и Direct Execution тоже. Кнопочка "расчитать новый план" делает прямую перекомпиляцию запроса + расчет плана:

stmt.executeUpdate('/*SP*/set noexec on')
stmt.executeUpdate('/*SP*/ '+msSqlStatement)
stmt.executeUpdate('/*SP*/set noexec off')
stmt.executeUpdate('/*SP*/set showplan_all on')
stmt.executeQuery('/*SP*/ '+msSqlStatement );
stmt.executeUpdate('/*SP*/set showplan_all off')

Так что по план в QA и AX должен быть одинаковым. К сожалению воспроизвести не могу ситуцию (обновил статистику) - сейчас планы одинаковые. Как замечу еще раз - обязательно проведу расследование.