Доброго дня и крепкого вам здоровья. Может быть натолкнёте меня

Question

Доброго дня и крепкого вам здоровья. Может быть натолкнёте меня

на какие-то мысли. Есть таблицы А и Б, таблицы соединяются по первичному ключу из таблицы А, в фильтре участвуют обе таблицы и тут начинается проблема – сортировка по полю из таблицы A. Запрос выглядит примерно вот так:

select A.Id from Б
join A on А.Id = Б.А_Id
where Б.Поле_Фильтр = @значение_для_фильтра
order by A.Поле_для_сортировки_типа_дата desc

Вот такой, казалось бы, совсем простой запрос. Но он таит в себе жутко неприятную вещь – в плане данное соединение ввиду количества данных в таблицах представляется как Nested Loops. Теперь осталось только правильно выбрать, по какой таблице начинать идти, а какую внутри проверять и вот она проблема. Большинство выборок where Б.Поле_Фильтр = @значение_для_фильтра имеют минимальное количество результатов на выходе (зачастую меньше даже 100, используя статистику сиквела всё логично) и сиквел успешно кэширует план, где цикл идёт по данным из таблицы Б и внутри по А, ну а после сортировку делает. Но вот есть такие моменты, когда where Б.Поле_Фильтр = @значение_для_фильтра вернет значительно большое количество элементов и если бы он шёл по таблице А, то эффективность просто значительно, очень значительно выше, учитывая то, что на ней есть индекс, где поле для сортировки уже отсортировано и повторной сортировки не нужно. Сейчас самое простое решение option (recompile), сиквел под новый параметр @значение_для_фильтра перестраивает план и всё хорошо, но сам вызов recompile несёт издержки. Есть идеи?

#programming #russian #sql

0

25.03.2022

1 ответов

12 просмотров

Mikhail Krupskiy · Accepted Answer

Mikhail Krupskiy

"несёт издержки" - огромные и невыносимые? работает же, что еще надо? )

0

25.03.2022

169 похожих чатов

Доброго дня и крепкого вам здоровья. Может быть натолкнёте меня

1 ответов

Похожие вопросы