RecId index (AX 2012 R3)

[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 индекс будет больше по размеру, плюс на большой табличке поиск по составному ключу может дать деградацию производительности. Т.е. я ожидал обратного эффекта.

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

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

[AnGor]

Цитата:

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

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

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

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

It's the test Environment.
28 companies and the table is not big - 1547records. In prod I will expect more records

[fed]

Цитата:

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

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

Если таблица имеет кластерный индекс, то index entry в некластерных индексах (наш случай), состоит из значения ключевых полей самого индекса и значения ключевых полей кластерного индекса. (Ну то есть - фактически поиск будет выполняться два раза - первый раз в нормальном индексе, потом по полученому значению ссылки - в кластерном индексе).
Если какое-то поле присутствует и в обычном индексе и в кластерном, то его значение в index entry обычного индекса не дублируется. Фактически в нашем случае, partitionId и dataareaId перехали из правой половины index entry в левую Поэтому добавление в обычный индекс полей из кластерного индекса не приводит к увеличению размера index entry.

[Alexius]

Цитата:

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

Мне казалось что во втором случае recid индекс будет больше по размеру

Индекс по RecId+Partition+DataAreaId ,будет больше по размеру индекса по одному полю RecId только при отсутствии кластерного индекса.