RecId index (AX 2012 R3)

[fed]

Еще интересно - что такое "медленный индекс". Время обновления может быть разным (в зависимости от списка полей в индексе), но его не очень легко замерить; Индекс может использоваться в типичных запросах чаще или реже; Индекс может снижать время каких-то конкретных запросов сильнее или слабее. Не очень понятно что именно имелось в виду...

[AnGor]

Цитата:

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

... Не очень понятно что именно имелось в виду...

имелось в виду, время выполнения запроса. В моем случае select firstonly InventJournalTable where InventJournalTable.RecId == _RecId

[Logger]

Цитата:

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

имелось в виду, время выполнения запроса. В моем случае select firstonly InventJournalTable where InventJournalTable.RecId == _RecId

А вы перед выполнение запроса делали ?
InventJournalTable.disableCache(true);

плюс еще не мешало бы кеш самого SQL сбросить. Была команда DBCC чего-то там по сбросу кеша сиквела.

Тогда уже можно сравнивать.

[fed]

Цитата:

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

плюс еще не мешало бы кеш самого SQL сбросить. Была команда DBCC чего-то там по сбросу кеша сиквела.

DBCC DROPCLEANBUFFERS()

[AnGor]

(sorry, I switch to english)
After run DBCC DROPCLEANBUFFERS the difference is not so huge.
This is the Timing with manual created index with dataareaid and Partition:

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 30 ms.

and this is the time after applying CreateRecIdIndex
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 40 ms.

This is the query which I used:
SELECT TOP 1 (list of all fields) FROM INVENTJOURNALTABLE T1 WHERE DATAAREAID=N'bvd' AND PARTITION=5637144576 AND RECID=5637148643

[fed]

Цитата:

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

(sorry, I switch to english)
After run DBCC DROPCLEANBUFFERS the difference is not so huge.
This is the Timing with manual created index with dataareaid and Partition:

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 30 ms.

and this is the time after applying CreateRecIdIndex
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 40 ms.

This is the query which I used:
SELECT TOP 1 (list of all fields) FROM INVENTJOURNALTABLE T1 WHERE DATAAREAID=N'bvd' AND PARTITION=5637144576 AND RECID=5637148643

Ну в целом - логично. У тебя в одном случае все поля условия выборки присутствуют в индексе, а во втором - только часть. Поэтому в первом случае система генерирует план запроса, который ищет по recId-индекс, а потом сразу получает всю запись целиком из кластерного индекса. Во втором случае - в получение записи целиком добавляется немножко CPUшного времени на фильтрацию по dataareaid и partition.

Если стоит задача максимально ускорить именно поиск по inventJournalTable, то попробуй искать не по recId, а по journalId. В этом случае - все будет обрабатываться в одну операцию - поиск по кластерному индексу. На вскидку - я бы ожидал что оно с 30ms до 15ms упадет.

[AnGor]

Цитата:

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

Если стоит задача максимально ускорить именно поиск по inventJournalTable, то попробуй искать не по recId, а по journalId. В этом случае - все будет обрабатываться в одну операцию - поиск по кластерному индексу. На вскидку - я бы ожидал что оно с 30ms до 15ms упадет.

My current task is to make queries faster
I analyze the statistic which I get from DynamicsPerf. After checking the missing Indexes for lazy queries I'm trying to speed up them by adding recommended Indexes. Before create the index in AOT I'm trying to create it direct in SQL. If the index makes effect I apply it on AOT. That's way how I found out that the query run faster if I add to the index DataAreId and Partition.

[Logger]

Цитата:

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

Во втором случае - в получение записи целиком добавляется немножко CPUшного времени на фильтрацию по dataareaid и partition.

Интересно. Мне казалось что во втором случае recid индекс будет больше по размеру, плюс на большой табличке поиск по составному ключу может дать деградацию производительности. Т.е. я ожидал обратного эффекта.

Нельзя назвать такой результат ожидаемым. Постфактум можно любое объяснение "привинтить".

Интересно, а сколько у них там записей всего в табличке и компаний.