Есть ли проблема с производительностью при использовании ISNULL() в SQL Server?

Ответ 1

Если вам нужно его использовать, то любые различия между ISNULL и альтернативами, такими как COALESCE или CASE, являются незначительными. Не беспокойтесь об этом

Любые различия исходят из того, как обрабатываются типы данных. COALESCE/CASE может добавлять неявные преобразования типа данных, тогда как ISNULL имеет более простые правила.

Изменить

ISNULL в списке SELECT для подавления NULLS является тривиальным. Основная работа будет выполнена при обработке строк и данных. Дополнительный ISNULL не будет поддаваться измерению: не оптимизировать преждевременно

Ответ 2

ISNULL() в предложении select оказывает незначительное влияние на производительность. С другой стороны, в where-clause это может очень сильно повлиять на производительность, поскольку оно не позволяет оптимизатору использовать индекс в этом столбце.

where isnull(col1, 0) = 0 -- unable to use index, because every 
                          -- row has to be evaluated

where col1 = isnull(@myVar, 0) -- index will be used, since isnull(@myVar, 0) 
                               -- returns the same static value for every row and 
                               -- not every row has to be evaluated by the function.

Таким образом, при использовании isnull() в where-where определите, не мешает оптимизатору запросов использовать индекс. Если это так, подумайте о создании вычисленного столбца с результатом if isull (col1, 0) и индексируйте вычисленный столбец и используйте его в вашем where-clause.

Ответ 3

Да, может. Для оптимизатора лучше переписать запрос (если возможно), чтобы сформировать

(Field = @x OR @x IS NULL)

Поскольку использование функций в определенных случаях не позволяет оптимизатору использовать статистику, а иногда и принудительное неявное преобразование типов данных

Ответ 4

Избегайте использования isNull в разделе where. См. Эта статья.

Ответ 5

Да, в SQL Server Studio 2012 есть проблема производительности afaik.

Проблема довольно вопиющая, когда я использовал ISNULL в сочетании с OVER. После оптимизации (т.е. Ввода ISNULL в подзапросе, в котором я использую OVER on) время выполнения сокращено с (оцененного) 25,2 часа до 102 секунд.

Мое предположение ISNULL в порядке, когда вы запускаете его по всему столбцу (например, в plain-ol 'SELECT). Но когда вы запускаете его с помощью OVER, он вызывается заново каждый раз, тем самым перетаскивая производительность.

Не готов к дальнейшему расширению. Просто разместив его здесь для справки других.

Ответ 6

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

Также я бы порекомендовал вам пройти это - Что делает предложение SQL обоснованным?

Ответ 7

Это зависит от того, как вы его используете, но может строить планы выполнения в обоих случаях (с помощью ISNULL() и без него) и сравнить результаты.