|
29.06.2017, 10:40 | #1 |
Участник
|
RecId index (AX 2012 R3)
интересный факт (возможно извесный):
анализируя запросы на предмет нехватки индексов, заметил следующую штуку: галочка CreateRecIdIndex и в ручную созданный индекс с полями DataAreId, Partition, RecId дают разный результат. CreateRecIdIndex создал очень тормознутый индекс, который в десятки раз медленнее созданного в ручную. все происходило с INVENTJOURNALTABLE мало того, в моем случае практически всегда было полезно добавлять в индекс DataAreId и Partition |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
29.06.2017, 10:56 | #2 |
Участник
|
А разница-то в чем? Можете выложить сюда скрипты создания обоих вариантов индекса?
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
29.06.2017, 11:05 | #3 |
Участник
|
это после CreateRecIdIndex:
CREATE UNIQUE NONCLUSTERED INDEX [I_154RECID] ON [dbo].[INVENTJOURNALTABLE] ( [RECID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] GO SQL Server Execution Times: CPU time = 0 ms, elapsed time = 46 ms. это ручной индекс: CREATE UNIQUE NONCLUSTERED INDEX [I_154VOL_RECIDX] ON [dbo].[INVENTJOURNALTABLE] ( [RECID] ASC, [DATAAREAID] ASC, [PARTITION] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] GO SQL Server Execution Times: CPU time = 15 ms, elapsed time = 4 ms. Последний раз редактировалось AnGor; 29.06.2017 в 11:07. |
|
29.06.2017, 11:08 | #4 |
Moderator
|
Еще интересно - что такое "медленный индекс". Время обновления может быть разным (в зависимости от списка полей в индексе), но его не очень легко замерить; Индекс может использоваться в типичных запросах чаще или реже; Индекс может снижать время каких-то конкретных запросов сильнее или слабее. Не очень понятно что именно имелось в виду...
|
|
29.06.2017, 11:12 | #5 |
Участник
|
|
|
29.06.2017, 11:22 | #6 |
Участник
|
Цитата:
InventJournalTable.disableCache(true); плюс еще не мешало бы кеш самого SQL сбросить. Была команда DBCC чего-то там по сбросу кеша сиквела. Тогда уже можно сравнивать. |
|
|
За это сообщение автора поблагодарили: AnGor (1). |
29.06.2017, 11:32 | #7 |
Moderator
|
|
|
|
За это сообщение автора поблагодарили: Logger (3), AnGor (1), alex55 (1). |
29.06.2017, 11:59 | #8 |
Участник
|
(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 |
|
29.06.2017, 11:10 | #9 |
Moderator
|
А - ну вот - понятно.
Последний раз редактировалось fed; 29.06.2017 в 11:15. |
|
29.06.2017, 11:15 | #10 |
Участник
|
Цитата:
это время выполнения запроса с первым и вторым индексом |
|
29.06.2017, 12:03 | #11 |
Участник
|
Еще вопрос как время меряли.
Таймер в аксапте меряет с точностью 15 миллисекунд. Поэтому кстати, не играет роли какая настройка долгих запросов стоит, 1 миллисекунда, 5 миллисекунд, 10 или 15. Так что может у вас и разницы то никакой нет. А просто статистическое отклонение. Надо провести хотя бы десяток измерений чередуя их сбросом кешей и тогда уже можно делать какие-то выводы. |
|
29.06.2017, 12:09 | #12 |
Участник
|
Цитата:
Сообщение от Logger
Еще вопрос как время меряли.
Таймер в аксапте меряет с точностью 15 миллисекунд. Поэтому кстати, не играет роли какая настройка долгих запросов стоит, 1 миллисекунда, 5 миллисекунд, 10 или 15. Так что может у вас и разницы то никакой нет. А просто статистическое отклонение. Надо провести хотя бы десяток измерений чередуя их сбросом кешей и тогда уже можно делать какие-то выводы. set statistics io on set statistics time on |
|
29.06.2017, 12:44 | #13 |
Участник
|
А можете еще попробовать такой индекс создать и померять
[PARTITION] ASC, [DATAAREAID] ASC, [RECID] ASC При такой конфигурации точно должно быть хуже. |
|
29.06.2017, 12:47 | #14 |
Участник
|
Надо бы еще планы запросов посмотреть.
В одном случае все условия фильтрации совпадают с полями индекса и план может быть один. А в другом совпадают только с одним полем и план запроса может быть не таким оптимальным. Наверно в этом собака зарыта. |
|
29.06.2017, 12:49 | #15 |
Участник
|
1547records - это ни о чем.
Сгенерируйте из джоба хотя бы 100 тысяч записей. Скорее всего картина изменится. Что же у вас за БД если из такой игрушечной таблицы она целых 40 миллисекунд запись отбирает ? |
|
29.06.2017, 13:13 | #16 |
Участник
|
для таблицы в 1500 записей вообще не рекомендуется строить индекса. Никакие! Фулскан будет быстрее, чем сначала индекс, потом в таблице...
__________________
Axapta 3.0 sp - хз какой, kr2 |
|
|
|