Небольшая предыстория. Запрос отработал более года и время выполнения его не превышало одной секунды. И в один из дней произошла сильная деградация время выполнения. Ниже текст запроса
ВЫБРАТЬ
АналитикаУчетаНоменклатуры.КлючАналитики КАК КлючАналитики
ПОМЕСТИТЬ Аналитики
ИЗ
РегистрСведений.АналитикаУчетаНоменклатуры КАК АналитикаУчетаНоменклатуры
ГДЕ
АналитикаУчетаНоменклатуры.Номенклатура = &Номенклатура
И АналитикаУчетаНоменклатуры.МестоХранения В(&МассивПартнеров)
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ТоварыПереданныеНаКомиссиюОстаткиИОбороты.АналитикаУчетаНоменклатуры.Характеристика КАК Характеристика,
ТоварыПереданныеНаКомиссиюОстаткиИОбороты.КоличествоПриход КАК Приход,
ТоварыПереданныеНаКомиссиюОстаткиИОбороты.КоличествоРасход КАК Расход,
ТоварыПереданныеНаКомиссиюОстаткиИОбороты.КоличествоКонечныйОстаток КАК Остаток,
ТоварыПереданныеНаКомиссиюОстаткиИОбороты.АналитикаУчетаНоменклатуры.Номенклатура КАК Номенклатура,
ТоварыПереданныеНаКомиссиюОстаткиИОбороты.Период КАК Дата,
ТоварыПереданныеНаКомиссиюОстаткиИОбороты.АналитикаУчетаНоменклатуры.Партнер КАК АналитикаУчетаНоменклатурыПартнер
ИЗ
РегистрНакопления.ТоварыПереданныеНаКомиссию.ОстаткиИОбороты(
,
,
День,
,
АналитикаУчетаНоменклатуры В
(ВЫБРАТЬ
Аналитики.КлючАналитики КАК КлючАналитики
ИЗ
Аналитики КАК Аналитики)) КАК ТоварыПереданныеНаКомиссиюОстаткиИОбороты
УПОРЯДОЧИТЬ ПО
Характеристика
ИТОГИ
СУММА(Приход),
СУММА(Расход),
СУММА(Остаток)
ПО
Номенклатура,
Характеристика
Показать
После недолго разбирательства всему виной стала операция агрегирования итогов до момента наложения отбора на таблицу, и дальнейшее использования tempdb
План запроса Вопрос почему так стало происходить остается открытым. Как исправил запрос после чего стал корректный план запроса, это перенес выборку из временной таблицы во вложенный запрос.
план запроса Вопроса в целом два почему так стало происходить и есть ли методы решения кроме изменения текста запроса.
Индекс во временную таблицу по ключу аналитики добавьте.
Почему? Ну, например, данных стало много, и оптимизатор решил все-таки мутнуть временную таблицу, в которой потерялся индекс - его ж никто не создал. В итоге хеш джоин, который уперся в создание вырожденной хеш-таблицы по большой и красивой основной таблице, в которой миллионы записей.
(3) Индекс не поможет т.к. в выборку верхней таблицы попадает 6 записей ( по конкретному примеру). И стандарт рекомендует индексирование ВТ с количеством записей > 1000
А пробовали? Планировщик сначала компилирует запрос, создавая план, оценивая количество по разным вариантам, а потом механизм просто берет и исполняет этот план, не разбираясь, мульон там записей или две. Вот сейчас он считает, что мульон, в итоге мерджит таблицы с помощью хеш-таблицы.
А когда Вы переносите ВТ в подзапрос, то, заметьте, начинает все крутиться быстрее. Почему? Ну так в оригинальной таблице соединяемое поле в индексе. Планировщику этой инфы хватает, чтобы не делать вырожденную хеш-таблицу.
Ну Вы же спрашиваете, почему? Вот вам вариант.