@ Мат, ты прав. Это имеет смысл, я не думал об этом. «Простое утверждение» - не вариант в нашей архитектуре. Но я проверил «простое утверждение» по отношению к базе данных напрямую, используя Toad (где я проводил анализ плана выполнения). На самом деле это ничего не изменило.
ь у меня действительно сложная задача с планами выполнения Oracle, использующими хаос, когда я используюDETERMINISTIC
функция на правой сторонеLIKE
оператор. Это моя ситуация:
Я подумал, что было бы разумно выполнить такой запрос (упрощенно):
SELECT [...]
FROM customers cust
JOIN addresses addr ON addr.cust_id = cust.id
WHERE special_char_filter(cust.surname) like special_char_filter(?)
И я бы связал?
что-то вроде'Eder%'
, В настоящее времяcustomers
а такжеaddresses
очень большие столы. Вот почему важно использовать индексы. Конечно, есть регулярный индекс наaddresses.cust_id
, Но я также создал индекс на основе функцийspecial_char_filter(customers.surname)
, который работает довольно хорошо.
Проблема в том, что приведенный выше запрос включаетlike
предложение создает планы выполнения с FULL TABLE SCANS наaddresses
, Похоже, что-то в этом запросе не позволяет Oracle использовать индексы наaddresses.cust_id
.
Я узнал, что решение моей проблемы заключается в следующем:
SELECT [...]
FROM customers cust
JOIN addresses addr ON addr.cust_id = cust.id
WHERE special_char_filter(cust.surname) like ?
Я удалила (DETERMINISTIC
!) функция из правой части оператора like и предварительный расчет переменной связывания в Java. Теперь этот запрос сверхбыстрый, без каких-либо полных таблиц сканирования. Это тоже очень быстро (хотя и не эквивалентно):
SELECT [...]
FROM customers cust
JOIN addresses addr ON addr.cust_id = cust.id
WHERE special_char_filter(cust.surname) = special_char_filter(?)
ПутаницаЯ не понимаю этого. Что плохого в том, чтобы иметь детерминированные функции в правой частиlike
оператор? Я наблюдал это в Oracle 11.2.0.1.0