Влияет ли на производительность использование неагрегированных функций SQL в столбце SELECTed?

У нас есть отчет, в котором используется длинный и сложный запрос с оператором SELECT, как показано ниже:

SELECT  
    NVL(nazwawystawcy,'BRAK') supplier_name, 
    NVL(AdresDostawcy,'BRAK') supplier_address,  
    NVL(NrDostawcy,'BRAK') supplier_registration, 
    DowodZakupu document_number, 
    DataZakupu document_issue_date,
    DataWplywu document_recording_date,
    trx_id,
    KodKrajuNadaniaTIN country_code,
    DokumentZakupu document_type_code,
    payment_split MPP,
    box_number box_number,
    box_amount box_amount,
    box_type box_type,
    display_order display_order
... 
FROM table1 t1
    ,table2 t2
....

Недавно мы внесли изменения в этот запрос и только что изменили третий столбец SELECTed, чтобы добавить REGEXP_LIKE.

SELECT  
    NVL(nazwawystawcy,'BRAK') supplier_name, 
    NVL(AdresDostawcy,'BRAK') supplier_address,  
    --NVL(NrDostawcy,'BRAK') supplier_registration, 
    Case When (NrDostawcy is not null and regexp_like(substr(NrDostawcy,1,2),'^[a-zA-Z]*$')) Then substr(NrDostawcy,3) else NVL(NrDostawcy,'BRAK') End supplier_registration,
    DowodZakupu document_number, 
    DataZakupu document_issue_date,
    DataWplywu document_recording_date,
    trx_id,
    KodKrajuNadaniaTIN country_code,
    DokumentZakupu document_type_code,
    payment_split MPP,
    box_number box_number,
    box_amount box_amount,
    box_type box_type,
    display_order display_order
... 
FROM table1 t1
    ,table2 t2
....

Я проверил планы объяснения обоих запросов, и оказалось, что они имеют одинаковое хеш-значение плана. Означает ли это, что на производительность не повлияет использование заполненных, неагрегированных функций SQL в столбцах SELECTed? Я считаю, что их использование в предложении WHERE влияет на производительность, но я не был уверен, относится ли то же самое к столбцам SELECTed.

Заранее извиняюсь, так как я не могу предоставить точный запрос, так как он является проприетарным и очень длинным и сложным. Я также не думаю, что смогу создать достаточно хороший образец, который соответствовал бы плану объяснения фактического запроса, поскольку он объединяет более 10 таблиц с тысячами строк данных.

Спасибо!


person Migs Isip    schedule 23.10.2020    source источник
comment
Я не думаю, что два разных запроса могут иметь одинаковое хеш-значение плана.   -  person GMB    schedule 23.10.2020
comment
Значения в списке выбора не влияют на фактический план выполнения, а только на часть projection. Вы можете проверить проекцию, чтобы понять, на каком шаге плана рассчитывается измененное значение, а затем попытаться заставить оракул вычислить его позже, если это необходимо. Влияние на производительность будет (но может быть относительно небольшим), потому что оракулу потребуется дополнительно применить regexp_like и substr ко всем значениям столбца NrDostawcy - вы можете просто проверить это, изменив regexp_like на некоторую функцию, которая спит несколько секунд, а затем возвращает переданный параметр.   -  person Dornaut    schedule 23.10.2020
comment
Это зависит. Добавление функций в столбцы потенциально увеличивает нагрузку на вычисление каждой строки, которую вы извлекаете (некоторые из ваших функций являются условными). Это может не отображаться очевидным образом в плане выполнения, поскольку эти функции обычно не влияют на способ получения необработанных данных, а только на то, что вы делаете с ними. Насколько сколько накладных расходов будет зависеть от конкретных функций и их количества, они могут быть незначительными в зависимости от набора данных. Небольшие наборы данных могут не иметь заметной разницы, в то время как большие наборы данных сильно пострадают.   -  person pmdba    schedule 23.10.2020


Ответы (3)


Поскольку вы выполняете этот запрос в Oracle, вот мой совет. Запустите запрос с подсказкой Oracle /*+ collect_plan_statistics */. Запустите его с первым запросом без регулярного выражения и с регулярным выражением. Затем найдите этот запрос в общем пуле (v$sql). Подсказка даст вам точное количество получаемых буферов, физических операций чтения, а также время, затрачиваемое на каждом этапе плана. С помощью этих данных вы можете подробно проанализировать, сколько времени требуется для выполнения запроса с регулярным выражением. Я советую вам делать это с данными, которые возвращают вам больше, чем, скажем, 10 тыс. строк. Таким образом, разница должна быть видна (если вы запустите это со 100 строками, разницы не будет).

person blazchar    schedule 24.10.2020

План выполнения такой же, как и для запроса одних и тех же данных из одних и тех же таблиц. Вы также должны увидеть, что объем данных (логический ввод-вывод) не изменился.

Однако время выполнения изменится, так как regexp_like будет потреблять больше ЦП, даже если вы увидите, что логический ввод-вывод не изменился.

Обратите внимание, что если вы изменили выбранные столбцы, план выполнения может измениться, как если бы все выбранные столбцы были частью индекса, оптимизатор может пропустить доступ к таблице и прочитать данные только из индекса.

person Andy Haack    schedule 24.07.2021

это зависит от запроса и операций ввода-вывода для получения данных. Иногда вы можете попробовать создать индекс на основе функций Oracle, вы можете увидеть некоторые улучшения.

Проверьте эту ссылку, она может вам помочь.

https://jeffkemponoracle.com/2007/11/will-oracle-use-my-regexp-function-based-index/

Спасибо

person hkandpal    schedule 23.10.2020
comment
Вы уверены, что IO и функциональные индексы имеют значение, когда речь идет о введении regexp_like использования в список выбора, который рассчитывается после того, как данные уже получены? - person Dornaut; 23.10.2020
comment
извините, но это на самом деле не отвечает на вопрос. я спрашиваю, есть ли какой-либо другой способ проверить, есть ли какое-либо снижение производительности, если я использую REGEXP в операторе SELECT, а не как улучшить его, добавив индекс. - person Migs Isip; 23.10.2020