А когда становятся необходимы индексы?

[Raven Melancholic]

Ну и, в первую очередь, многое зависит от самих данных в этих полях. То есть, то будет ли индекс селективным. Если смотреть на этот запрос, то тут явно:

• Поле PARMJOBSTATUS со значением 0, неселективно (все таки, большая часть документов разносится).
• Поле ORDERING уже получше, но зависит от того, какую часть в общем числе записей составляют отборочные накладные.
• Поле DATAAREAID селективность зависит от того, одна ли у Вас компания, если несколько, то равномерно ли распределены записи в разных компаниях или компания comp является преобладающей или наоборот редкой.
• Так что для данного запроса все зависит от частоты появления ИД14213833. Если это всегда уникальное или нечасто встречающееся значение, то индекс должен помочь. В противном случае бесполезен.

В зависимости от селективности SQL и будет решать использовать индекс или нет. Кроме того, нужно еще учесть свежесть статистики, иначе решение может быть ошибочным.
Как-то так.

[Perc]

Цитата:

Сообщение от Raven Melancholic

Ну и, в первую очередь, многое зависит от самих данных в этих полях. То есть, то будет ли индекс селективным. Если смотреть на этот запрос, то тут явно:..

Да, согласен с тем что таблица эта была зря использована при проектировании. Но так уже случилось. Отборочных в нашем случае в этой таблице как раз большинство. больше половины. Компания фактически одна. Поле f1 это аналог parmId. Связка отборочных по некому нашему условию обработки. Но повторяемость этого значения максимум 4-5 записей. Выборки аналогичные этому запросу по параметру у нас делаются во многих местах и в обработке документов и в отчетах даже. Поэтому то я и обратил внимание поле запроектировано, используется, а индекса нет. Причем тормозов на таких запросах особо не заметил. Но вроде как интуиция подсказывает что индекс должен быть. Решил поэкспериментировать добавить индекс. Да, план запроса в SQL меняется на использование индекса. Но улучшения на порядок или даже в разы, как было в других похожих случаях, не обнаружено. И это мне показалось странным. Возможно конечно допуская я както не некорректно проводил тест. Но как тогда правильно проверить эффективность добавления индекса?

[Raven Melancholic]

Между экспериментами буферы на MS SQL сбрасывали?
Судя по

Цитата:

Но повторяемость этого значения максимум 4-5 записей

и

Цитата:

план запроса в SQL меняется на использование индекса

Разница на 1,5 миллионах записей должна ощущаться.
Кстати, поле F1 в индексе первым идет (ну, не считая DATAAREAID)?

[Perc]

Цитата:

Сообщение от Raven Melancholic

Между экспериментами буферы на MS SQL сбрасывали?

Нет, не сбрасывали. А как)?

Индекс да, вроде правильно делали в репозитарии аксапты. В индекс только f1 и добавлял. Ну да я и говорю. индекс добавляешь, sql показывает в плане запроса что использует новый индекс.
Ну тем не менее в данном случае склоняюсь что индекс должен быть. сделаю.

[gl00mie]

Цитата:

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

В таблице около 1,5 млн записей. Индексов по упомянутым в условии полям нет. Я наконец задумался, а с какого объема таблицы надо задумываться об индексах по поисковым полям? SQLSrver если чо 10.50.4000.0

Цитата:

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

Нет, не сбрасывали. А как)?
Ну тем не менее в данном случае склоняюсь что индекс должен быть. сделаю.

Чем обсуждать какой-то частный случай, который к программированию в Аксапте относится весьма опосредованно, не лучше ли почитать что-то более близкое к теме создания индексов? В тех же SQL Server Books Online есть статьи на эту тему, например, Creating and Maintaining Databases/Indexes/Designing an Index - пусть и древняя, но с учетом уровня обсуждения вполне подходящая.