КА2.0 В типовой конфе в спр.Номенклатура добавлен реквизит "AB_Партнер" (кому-то взбрело это сделать в голову вместо доп реквизитов). Потом по этому реквизиту планируется сделать фильтр в списке номенклатуры. Суть в том, что простейший запрос зависает.

ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ ПЕРВЫЕ 51
    ТаблицаСправочника.AB_Партнер
ИЗ
    Справочник.Номенклатура КАК ТаблицаСправочника
ГДЕ
    ТаблицаСправочника.ВидНоменклатуры = &ВидНоменклатуры

Такой запрос виснет. Причем если выбирать, к примеру, два поля Ссылка и AB_Партнер, то все норм. Пробовал делать реиндексацию таблиц, толку никакого. В чем косяк?

проиндексируй реквизит

упорядочить по ссылка

(0) Естественно быстрей будет. Ссылка ж проиндексирована и он выберет первые 51 различные разрешенные ссылки)))
делай как в (1) сказано.

>> кому-то взбрело это сделать в голову вместо доп реквизитов
Все правильно сделали!

(1) (3) Да, тут понятно. Но как проиндексировать? Запрос менять не вариант. У реквизита Использование стоит Индексировать. В базе запускал переиндексацию таблиц. Не фурычит.

Какой смысл брать "Первые N" без упорядочивания?

РЛС используется кстати?

(6) Это уже вопрос к создателям типовой конфы. Запрос собирается типовым алгоритмом и дальше как-то юзается. Суть не в этом.


ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 51
работает хорошо, за 0.1сек

Но проблема в том, что менять сам запрос не очень хорошо, может сломаться что-то в другом месте.

посмотри план запроса

А тип какой у реквизита?

Если не понимать что делает запрос, лучше в него совсем не лезть.

По сабжу: если реквизит индексируется, то вангую что в справочнике миллион записей, а поле текстовое неограниченной длины.

(10) "текстовое неограниченной длины" нельзя на равенство сравнить

(0) группировку сделай

(10) Поле АВ_Партнер - это ссылка на спр.Партнеры. В справочниках Партнеры и Номенклатура много записей, но не более 10000.
(12) Группировка да, работает быстро. Но есть большое НО. Запрос менять нельзя, там типовой кусок. Запрос формируется из алгоритма, там куча if. Конечный запрос не всегда такой маленький и красивый.

Могу предположить, что проблема в кластерном индексе. Суть на сколько помню в том, что индекс хранится в виде Ссылка+Наименование+АВПартнер, и если условие только на АВПартнер - то MSSQL его не использует. Попробуйте изменить запрос - сперва получать Ссылка+АВПартнер (например, во временную таблицу, а потом уже только АВпартнер выводить).

Точный ответ даст только профайлер.

(13) "типовой кусок" и "добавлен реквизит "AB_Партнер"" уже явно говорит о том, что конфигурация не типовая. Выбирай, либо шашечки, либо ехать, либо выкинь всё это в доп реквизит и заполни его по документам, а из конфы реквизит удали.

(13) ответ в (1).

(14)
А зачем настаивать на том, чтобы тут использовался именно кластерный индекс?

(0) Убери "РАЗЛИЧНЫЕ "

(0)
На 10000 записей такой запрос не должен зависать при любых сочетаниях индексов.

Ты недоговариваешь. Ну или "зависать" - это 10 секунд выполняться.

(7) Индексируй "AB_Партнер"

+(7)  Убери "РАЗРЕШЕННЫЕ ", дай всем права на чтение этого справочника :)

+ Добавь "Группировать По AB_Партнер"

Попробуй так

ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ ПЕРВЫЕ 51
    Выразить(ТаблицаСправочника.AB_Партнер Как Справочник.Партнеры)
ИЗ
    Справочник.Номенклатура КАК ТаблицаСправочника
ГДЕ
    ТаблицаСправочника.ВидНоменклатуры = &ВидНоменклатуры

(0) Индексировать надо реквизит ВидНоменклатуры  так как по нему идет поиск.
Реквизит AB_Партнер  можно не индексировать в этом случае так как по нему нету ни поиска ни сортировки. Посмотри проиндексирован ли реквизит ВидНоменклатуры.

(23) эта конструкция используется только при получении данных через точку от поля составного типа и используется всегда в купе с Ссылка, так от него толку вообще нету.

(14) поиск идет по полю ВидНоменклатуры, Кластерный индекс тут никак не поможет.

(0) разрешенные различные тоже сложная конструкция, если количество записей огромной может приветс и в hash aggregate на уровне субд а это не очень хорошо.

(24) индекс по AB_Партнер может работать, когда вообще нет в запросе отборов/сортировок. Просто потому, что он покрывает результат запроса, весит меньше кластерного и даёт упорядоченный результат, что позволяет скулю заюзать Stream Aggregate для выполнения РАЗЛИЧНЫЕ.

Всё ломается, когда добавляются поля, непокрытые индексом(в данном случае - вид номенклатуры).

отбор надо делать через внутреннее соединение, а не в где.

(29)
*Бьет головой в стену*
Что побуждает писать подобное? Как это возникает?

> Что побуждает писать подобное? Как это возникает?

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

(18) (21) Это может изменить логику запроса - в выборку станут попадать уже не те данные, что раньше. Думаю, у автора там уорядочивание-таки есть в его настоящем запросе, это он упростил, не ведая.