Почему сокращение условий WHERE не приводит к ускорению выполнения запроса?

Поступил запрос с таким условием:

  and (c.COL like '@p%'
   or c.COL like '@P%'
   or c.COL like '@р%'
   or c.COL like '@Р%'
   or c.COL like '@C%'
   or c.COL like '@c%'
   or c.COL like '@с%'
   or c.COL like '@С%'
   or c.COL like '@R%'
   or c.COL like '@r%'
   or c.COL like '@p um%'
   or c.COL like '@P um%'
   or c.COL like '@р um%'
   or c.COL like '@Р um%'
   or c.COL like '@kpr%')

В текстовом поле COL встречаются в разных регистрах как Р/С русская, так и Р/С английская, поэтому они продублированы. При сокращении условия до такого состояния:

and (lower(c.COL) like '@p%'
   or lower(c.COL) like '@р%'
   or lower(c.COL) like '@c%'
   or lower(c.COL) like '@с%'
   or lower(c.COL) like '@r%'
   or Purpose like '@kpr%')

запрос выполняется даже дольше. Хотя избыточные like '@p um%' отсутствуют, и в целом альтернативных условий стало меньше. Почему так? Это влияние функции lower()?


Ответы (1 шт):

Автор решения: Герман Борисов

В первом случае все условия LIKE проверяют начало строки. При этом возможно использование индекса, так как c.COL like '@P%' эквивалентно c.COL >= '@P' and c.COL < '@Q'.

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

Поэтому при более-менее большом количестве записей (от нескольких сотен) второй вариант работает дольше.

Возможные выходы:

  1. Изменить тип столбца на регистронечувствительный.
  2. Построить индекс по lower(c.COL)
→ Ссылка