Добрый день,

Помогите понять в чем может быть следующая проблема.

Сервер - Microsoft SQL Server 2014 (SP2-GDR) (KB4019093) - 12.0.5207.0 (X64)
Есть процедура, которая начинается со следующей простой выборки:




Суть этой выборки - найти список строк в tblOutLets, который по заданным столбцам отсутствует в OutletsAudit.

Если подствить нужный мне период в выборку из первой таблицы, то я получаю результат в размере ~315 тыс строк.
Если выполнить отдельно второй запрос, то получаю результат в размере ~290 тыс строк.
Если выполнить целиком c EXCEPT, то получаю результат в размере ~43 тыс строк. При этом время выполнения составляет
План выполнения этой выборки во вложении "1.sqlplan"


Если запустить выполнение этого куска кода в рамках процедуры, то у меня процедура залипает на этом участке и висит бесконечно. Растет CPU, количество чтений в пределах 10-15.
Это не всегда так. Данная проблема у меня впервые появилась на тестовой среде и тогда я ничего не смог поделать с ней (сбрасывал кеши планов, запускал процедуру с рекомпиляцией) и только пересоздание процедуры решило проблему.
Сейчас эта проблема всплыла на продуктиве у клиента. Вариант - удалить и заново создать не вариант. Надо понять причину такого поведения.
План выполнения той же выборки, но запущенной в рамках процедуры "2.sqlplan"

Очень интересная картина выходит по планам. В первом случае видно, как он тянет много строк, а во втором ничего.


Спасибо!

P.S. Не судите строго, но я не смог понять, как приложить 2 плана по отдельности, поэтому архивом приатачил.

Maxxмщдя... а то что у вас разные запросы никого не волнует ?? да и в обоих случаях у вас просят создать нужный индекс ?
Вы о том, что я убрал INTO в первом варианте?
Вот вместе с INTO план во вложении

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

TaPaKну и сравнивать Actual vs Estimate из рвзных мест это всегда весело.

авторОчень интересная картина выходит по планам. В первом случае видно, как он тянет много строк, а во втором ничего.

a NL vs Hash вас не смутил... в общем курите ссылку
Спасибо за ссылку. Сейчас буду пытаться разобраться.
Что касается планов, то первый я получил актуальный после обычной выборки, а второй взял из процедуры sp_WhoIsActive (Adam Machanic). Эта процедура разве Estimate план выдает? Только что проверил свою процедуру на другом сервере и там sp_WhoIsActive нарисовал план с большим потоком данных в отличии от того, что на продуктиве сейчас, где по 1 строке возвращает.

TaPaKa NL vs Hash вас не смутил... в общем курите ссылку
Моих знаний на текущий момент недостаточно, чтобы понять почему при обычной выборке он решил использовать Hash match, а внутри процедуры NL...

Товарищ TaPak натолкнул на мысль о разнице между физическим соединением.
Я не любитель использовать OPTION, привык, что SQL сам найдет правильное решение, но в данном конкретном случае явно указал для своего скрипта внутри процедуры



После этого процедура выполнилась быстро и правильно.


Еще я попробовал перед запуском процедуры обновить статистику для указанных 2-х таблиц и после запускать процедуру.
Результата ноль.
Далее я взял и запихнул обновление статистики по 2-м таблицам в саму процедуру перед выполнением своей выборки.
Результат - процедура выполнилась быстро и правильно.

Для меня эта мистика какая-то.
Буду читать ваши ссылки, может чего пойму...

aleks222,

Мы вроде бы на одном языке общаемся, но я многое не понимаю ))
Жизнь боль, а эффект Даннинга-Крюгера сила.

TaPaKotets1988,
прибить хешем это конечно агонь. Но статью вы решили не открывать...
С чего вы решили, что я статью решил не открывать?
Если бы она была короткой, то я бы ее сразу прочитал, а так как она очень приличного размера, а решить проблему надо было немедленно, то я решил что-то сперва делать. Пусть это будет сейчас затычка без понимания сути.
Но зато я теперь могу спокойно попытаться разобраться в сути пока затычка стоит и не давит на меня.

otets1988Буду читать ваши ссылки, может чего пойму...