Филтриране (NULL IS NOT NULL) Операция и заявки с обвързани променливи, механика на Oracle

Производителност на СУБД и свързани проблеми

При изпълнение на заявка с NULL стойности на обвързани променливи, условия от типа КОЛОНА1 =: VAR1 превръщам се в КОЛОНА1 = НУЛА и по дефиниция те стават неработещи (в смисъл, че заявка с такова условие в WHERE не връща редове), но когато изгражда план/изпълнява заявка, оптимизаторът не винаги използва тази възможност за спестяване на ресурси

Например, при изпълнение на практическа заявка (съдейки по текста, който проверява дали текстът, въведен в полето на формуляра, съвпада с идентификатора на потребителя или потребителското име на клиента) с празна стойност на променливата:

- заявката се изпълнява по същия начин, както за не-NULL стойности на променливи, със същото значително количество ненужни четения на блокове в базата данни в този случай

Същата заявка без използване на обвързани променливи работи много по-ефективно:

- общите разходи за изпълнение на заявка се оказват по-ниски от разходите за добавките: при очевидно невъзможни условия ненужните операции за достъп до база данни се изключват от оператора на филтъра (NULL IS NOT NULL)

Или за тестов случай:

- и отново, въпреки ненулевите разходи за сканиране T1, цената на цялата заявка = 0, което е логично - заявката за получаване на резултата не се нуждае от данни в базата данни

Тъй като таблицата в този пример е "прясна" (без статистика) според стойността по подразбиране на параметъра:

допълнително се извършва излишна операция динамично вземане на проби след получаване на стойностите на обвързаните променливи (което е важно за заявки с обвързани променливи), вече на етапа на избор на метод за достъп за таблицата:

---