Подтвердить что ты не робот

Почему обертка TSQL-запроса в выражении if значительно увеличивает время выполнения?

У меня возникает нечетная разница в производительности при запуске одного и того же запроса двумя разными способами. Буквально, единственное различие заключается в том, заключен ли он в оператор if.

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

Выполнение запроса само по себе возвращает почти сразу (возвращает 0)

select COUNT(*) from Responses r where r.ResponseID not in (
    select ResponseID from data.GamingReport_Computerized
))

В конечном счете, я хочу избежать выполнения сложных вычислений на основе результата этого запроса, поэтому я переношу его в оператор if так, но это займет намного больше времени (~ 10 секунд), и я не могу понять почему:

if (0 = (select COUNT(*) from Responses r where r.ResponseID not in (
    select ResponseID from data.GamingReport_Computerized
)))
begin select 'update will be skipped to save time' end
else begin select 'missing rows will be inserted' end

Набор данных не изменяется, поэтому в обоих случаях результат равен нулю/'обновление будет пропущено', и все же запуск этих двух версий одного и того же запроса всегда приводит к быстрому завершению первой версии, а вторая версия 10-12 секунд для завершения.

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

Query Execution PlansDetailed Index Scan/Seek performance

Обновление 2: В ответ на предложение в комментариях я хотел бы упомянуть, что следующий запрос выполняет идентично второй версии выше, с тем же планом выполнения и без увеличения производительности (т.е. используя "существует" вместо сравнения счетчик (*) до нуля не имеет значения).

if exists(select 1 from Responses r where r.ResponseID not in (
    select ResponseID from data.GamingReport_Computerized
))
begin select 'missing rows will be inserted' end
else begin select 'update will be skipped to save time' end
4b9b3361

Ответ 1

Я столкнулся с этой проблемой раньше (довольно много раз). Можете ли вы проверить, являются ли ваши индексы фрагментированными (и дефрагментация их при необходимости), а статистика обновлена? Это может сильно повлиять на производительность и, вполне возможно, проблема (поскольку поиск занимает больше времени, чем сканирование).

Ответ 2

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