Цитата:
Сообщение от
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 упадет.