AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 21.08.2014, 06:13   #1  
Perc is offline
Perc
Участник
 
193 / 44 (2) +++
Регистрация: 05.03.2005
А когда становятся необходимы индексы?
так случилось что на таблице SalesParmTable у меня есть дополнительное поле f1. В Dax4 пишу запрос с фильтром по этому полю который в итоге в sql превращается в запрос
X++:
SELECT A.f1,A.PARMID 
FROM salesparmTable A 
WHERE ((DATAAREAID=N'comp') AND (((F1=N'ИД14213833') AND (ORDERING=5)) AND (PARMJOBSTATUS=0)))
В таблице около 1,5 млн записей. Индексов по упомянутым в условии полям нет.
По ощущениям запрос исполняется одинаково мгновенно - что есть индекс по полю F1 что нет.
Я наконец задумался, а с какого объема таблицы надо задумываться об индексах по поисковым полям?

SQLSrver если чо 10.50.4000.0
Старый 21.08.2014, 10:08   #2  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Может поможет http://blogs.msdn.com/b/axinthefield...namics-ax.aspx
Старый 21.08.2014, 17:22   #3  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Мне кажется, что тут больше не в количестве записей дело. Смотреть и экспериментировать нужно на реальной базе в реальных условиях, например, как часто выполняются запросы. Если такой запрос 1 в день, то вряд ли нужно делать отдельный индекс. Не исключено, что у Вас разница небольшая из-за того, что в базе только Вы и больше никто не обращается к этой таблице.
PS: вопрос не по индексу, а уже по подходу к данным. А что делает в SalesParmTable 1,5 миллиона записей? Это же таблица только на время разноски и, может быть, для каких-то разборок некоторое время после разноски (типа посмотреть, были ли ошибки с тем же документом в прошлые попытки). Её же, по хорошему, нужно периодически чистить.
Я видел пару реализаций, в которых данные этой таблицы использовались в отчетах и даже в логике функционала, но это явно были ошибки проектирования - такие поля, если они требуются, нужно тянуть в сами документы.
Старый 21.08.2014, 17:41   #4  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Ну и, в первую очередь, многое зависит от самих данных в этих полях. То есть, то будет ли индекс селективным. Если смотреть на этот запрос, то тут явно:
  • Поле PARMJOBSTATUS со значением 0, неселективно (все таки, большая часть документов разносится).
  • Поле ORDERING уже получше, но зависит от того, какую часть в общем числе записей составляют отборочные накладные.
  • Поле DATAAREAID селективность зависит от того, одна ли у Вас компания, если несколько, то равномерно ли распределены записи в разных компаниях или компания comp является преобладающей или наоборот редкой.
  • Так что для данного запроса все зависит от частоты появления ИД14213833. Если это всегда уникальное или нечасто встречающееся значение, то индекс должен помочь. В противном случае бесполезен.
В зависимости от селективности SQL и будет решать использовать индекс или нет. Кроме того, нужно еще учесть свежесть статистики, иначе решение может быть ошибочным.
Как-то так.
За это сообщение автора поблагодарили: mazzy (2).
Старый 22.08.2014, 04:48   #5  
Perc is offline
Perc
Участник
 
193 / 44 (2) +++
Регистрация: 05.03.2005
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Ну и, в первую очередь, многое зависит от самих данных в этих полях. То есть, то будет ли индекс селективным. Если смотреть на этот запрос, то тут явно:..
Да, согласен с тем что таблица эта была зря использована при проектировании. Но так уже случилось. Отборочных в нашем случае в этой таблице как раз большинство. больше половины. Компания фактически одна. Поле f1 это аналог parmId. Связка отборочных по некому нашему условию обработки. Но повторяемость этого значения максимум 4-5 записей. Выборки аналогичные этому запросу по параметру у нас делаются во многих местах и в обработке документов и в отчетах даже. Поэтому то я и обратил внимание поле запроектировано, используется, а индекса нет. Причем тормозов на таких запросах особо не заметил. Но вроде как интуиция подсказывает что индекс должен быть. Решил поэкспериментировать добавить индекс. Да, план запроса в SQL меняется на использование индекса. Но улучшения на порядок или даже в разы, как было в других похожих случаях, не обнаружено. И это мне показалось странным. Возможно конечно допуская я както не некорректно проводил тест. Но как тогда правильно проверить эффективность добавления индекса?
Старый 22.08.2014, 11:31   #6  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Между экспериментами буферы на MS SQL сбрасывали?
Судя по
Цитата:
Но повторяемость этого значения максимум 4-5 записей
и
Цитата:
план запроса в SQL меняется на использование индекса
Разница на 1,5 миллионах записей должна ощущаться.
Кстати, поле F1 в индексе первым идет (ну, не считая DATAAREAID)?
Старый 24.08.2014, 11:18   #7  
Perc is offline
Perc
Участник
 
193 / 44 (2) +++
Регистрация: 05.03.2005
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Между экспериментами буферы на MS SQL сбрасывали?
Нет, не сбрасывали. А как)?

Индекс да, вроде правильно делали в репозитарии аксапты. В индекс только f1 и добавлял. Ну да я и говорю. индекс добавляешь, sql показывает в плане запроса что использует новый индекс.
Ну тем не менее в данном случае склоняюсь что индекс должен быть. сделаю.
Старый 25.08.2014, 12:31   #8  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Perc Посмотреть сообщение
В таблице около 1,5 млн записей. Индексов по упомянутым в условии полям нет. Я наконец задумался, а с какого объема таблицы надо задумываться об индексах по поисковым полям? SQLSrver если чо 10.50.4000.0
Цитата:
Сообщение от Perc Посмотреть сообщение
Нет, не сбрасывали. А как)?
Ну тем не менее в данном случае склоняюсь что индекс должен быть. сделаю.
Чем обсуждать какой-то частный случай, который к программированию в Аксапте относится весьма опосредованно, не лучше ли почитать что-то более близкое к теме создания индексов? В тех же SQL Server Books Online есть статьи на эту тему, например, Creating and Maintaining Databases/Indexes/Designing an Index - пусть и древняя, но с учетом уровня обсуждения вполне подходящая.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Стандартные неиспользуемые индексы Link DAX: Программирование 14 06.02.2014 14:48
когда в строке накладной(custInvoiceTrans) в поле LineAmount (Amount) значение не равно qty*Price? IKA DAX: Функционал 5 11.02.2010 12:22
Перестали работать индексы в запросах Antant DAX: Администрирование 2 03.08.2009 19:01
При каждом обращении строит индексы в Old nicko DAX: Администрирование 0 16.02.2005 08:57
Мастер шаблонов Excel падает когда вставляет в Excel поле, не основанное на EDT Ace of Database DAX: База знаний и проекты 5 25.10.2004 18:19
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:47.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.