Доброго времени суток.

1С 8.2.19.106
В базу добавил индекс по номенклатуре для регистра ПартииТоваровНаСкладах

Есть такой запрос:

ВЫБРАТЬ
    ПартииТоваровНаСкладах.Номенклатура КАК Номенклатура,
    ПартииТоваровНаСкладах.Количество
ИЗ
    РегистрНакопления.ПартииТоваровНаСкладах КАК ПартииТоваровНаСкладах
ГДЕ
    ПартииТоваровНаСкладах.Номенклатура = &Номенклатура

В плане запроса используется Clustered Index Scan.

Кто-нибудь может сказать, почему не используется индекс по номенклатуре?

потому, что номенклатура - не первое измерение, видимо

(0)

[ОРРХ | ОРНР1 +] Измерение + Период + Регистратор + НомерСтроки

Измерению "Измерение" задано свойство "Индексировать".

Есть ли разделители?

+(1) это ответ на вопрос, "Почему scan, а не seek".
А ответ на вопрос, почему скнируется кластерный индекс, а не индекс по измерению, - потому, что у тебя в выборке номенклатура и ее выгоднее сразу получить из кластера, чем сначала найти на нее указатель и потом получить ао указателю.

(2) да нормально все - тут кластерный и надо было использовать. Оптимизатор, который в sql, в данном случае оказался умнее оптимизатора, который за клавиатурой

(3) + если в таблице небольшое количество записей и эти записи в большинстве своем "уникальны".

(4) Согласен, что оптимизатор решает все сам... надо смотреть статистику.

(3) в (2) не указано что индекс кластерный.

(0) Я призываю вообще отказаться от кластерного индекса.
Удали его и посмотри как быстрее начнет работать запрос.

(9) Экстрим ))))

может надо просто обновить статистику или еще чего... Либо есть объективные предпосылки.

Потому что селективность (номенклатура часто встречается у тебя в регистре и оптимизатор решает, что неразумно искать по индексу и выбирает сканирование всей таблицы)

Разделителей нет.
Поле проиндексировано.
Не важно, какое это измерение, это же не таблица итогов, нету автоиндекса по измерениям (но оно таки первое).

Результат запроса - 26 000 записей
Всего записей в регистре - 819 000

Статистику обновлял перед тестом, делал
UPDATE STATISTICS dbo._AccumRg26165 WITH FULLSCAN
потом
DBCC FLUSHPROCINDB(14)

(11) См. (10) и узбагойся

Может, действительно оптимизатору выгоднее здесь сканировать кластерный индекс.

А вообще эта задача выросла из другой: если ограничить ещё в запросе по периоду, то будет Clustered Index Seek по периоду, хотя можно было бы сделать Index Seek по индексу с номенклатурой (там первое поле номенклатура, второе период).

Если такой запрос выполнится в транзакции, то он заблокирует весь месяц, хотя мог бы заблокировать только по конкретной номенклатуре в пределах месяца.
Думаю, может чего-то у меня с индексом не так или есть пути обхода.

Ну раз нет, то придётся смириться...

(7) и чо теперь?

(13) ты рассуждаешь о материях, которых не понимаешь

(15) Чего же я не понимаю?

(16) ты не понимаешь, почему оптимизатор выбрал кластерный индекс и не понимаешь, почему это было правильное решение.

(17) Я могу это понять. Но чтобы лучше это понимать я об этом тут и рассуждаю. Вот ты мне на вопрос ответил и я стал ближе к пониманию. Спасибо тебе.

Когда буду изучать работу оптимизатора обязательно обращу внимание на то, в каких случаях и насколько кластерный индекс предпочтительнее некластерного (насколько тяжело искать данные по указателям)

(18) рекомендую к курению настольную книгу эксперта по технологическим вопросам

(19) Я её уже 2 раза скурил, но что-то по данному вопросу ответ пропустил.

Может там это надо между строк читать? Это в теме про индексы или планы запросов? Обязательно перечитаю.

(13) вроде в режиме снэпшот чтение ничего не блокирует

Чой-та я устал намекать. Автор, попробуй номенклатуру из выборки уже убрать - ее из базы бестолку выбирать, ты ее до выполнения запроса и так знаешь

(21) 1С 8.2.19.106

В режиме снэпшот действительно блокировать не будет.
Но у меня не режим снэпшот. А переводить SQL в другой режим в обход механизмов платформы - слишком радикальное решение для моей проблемы.

хотя нет, все равно будет Clustered Index Scan потому, что отборов по предыдущим измерениям нет

(22) Ну это тестовый пример. На самом деле там всё несколько сложнее, я просто разбираюсь поэтапно. Данный момент мне был не понятен, поэтому я сюда и написал.

Убрал количество - теперь нужный индекс используется.
Действительно, стоило протестировать вариант, когда индекс покрывающий.