Подстановка значения NULL на константу - PullRequest
2 голосов
/ 28 сентября 2010

Ради забавы я сегодня играл со встроенным оптимизатором для Oracle в Toad.Одна из оптимизаций, которую он предлагает, заключается в следующем:

AND emp.pay_type = NVL('FT', UID)

Вместо

AND emp.pay_type = 'FT'

Я запутался в том, что здесь происходит, и из-за этого запутался в том, почемуулучшить производительность.Так как FT является строковым литералом в запросе SQL и, следовательно, никогда не NULL, почему это будет иметь значение?Я предполагаю, что это как-то связано с существующим индексом на месте, но я не могу найти что-либо в документации Oracle.

Ответы [ 3 ]

4 голосов
/ 28 сентября 2010

Это странный совет. Функция NVL работает следующим образом:

NVL(exp1, val1)

Если 'exp1' не равно нулю, оно возвращается; в противном случае возвращается «val1».

Поскольку в данном примере «FT» не может иметь значение NULL, использование функции NVL бесполезно и небольшое снижение производительности (по крайней мере, для оптимизатора выясняется, что NVL является избыточным; возможно, штраф за выполнение, если оптимизатор) не получается, что NVL избыточен).

Если условие читается:

AND emp.pay_type = NVL ("FT", UID)

тогда может быть польза; здесь у нас есть идентификатор с разделителями (имя столбца заключено в двойные кавычки), и значение столбца может быть NULL; вызов NVL гарантирует, что NULL будет возвращен, только если «FT» равен NULL , а UID равен NULL. UID - это, конечно, обычный идентификатор.

Это может иметь смысл, если условие гласит:

AND emp.pay_type = NVL(UID, 'FT')

Теперь, если значение UID равно NULL, в качестве соответствующего pay_type используется значение по умолчанию «FT».

3 голосов
/ 28 сентября 2010

Я бы взял «предложения по оптимизации» от жабы с огромными зернами соли.Я называю их методом оптимизации «дробовик» - стреляйте в цель целым рядом разных битов и смотрите, какой из них попадет, так или иначе:)

В любом случае, разница между

AND emp.pay_type = NVL('FT', UID)

и

AND emp.pay_type = 'FT'

. Во втором случае оптимизатор может использовать статистику гистограммы для столбца (если они были собраны), чтобы получить более точную оценку числа совпадающих строк.Однако при использовании NVL оптимизатор (я считаю) не обнаружит, что он может игнорировать NVL, и поэтому не будет проверять гистограмму на предмет значения.

Это не метод оптимизации, который я бы обычно использовалиспользовать.Существуют более эффективные способы контроля пути выполнения запроса (например, подсказок).В частности, этот метод потерпит неудачу, если они улучшат CBO для поиска и оптимизации избыточного кода, например от NVL([literal value],[anything]) до [literal value].

1 голос
/ 28 сентября 2010

Что план объяснения Oracle расскажет вам о двух запросах?

...