Стоимость логики в запросе

Question

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

select xmlelement("rootNode",
    (case
       when XH.ID is not null then
     xmlelement("xhID", XH.ID)
       else
     xmlelement("xhID", xmlattributes('true' AS "xsi:nil"), XH.ID)
    end),
    (case
       when XH.SER_NUM is not null then
     xmlelement("serialNumber", XH.SER_NUM)
       else
     xmlelement("serialNumber", xmlattributes('true' AS "xsi:nil"), XH.SER_NUM)
    end),
/*repeat this pattern for many more columns from the same table...*/
FROM XH
WHERE XH.ID = 'SOMETHINGOROTHER'

Это некрасиво, и мне это не нравится, и это также самый медленный запрос (есть другие похожие по форме, но гораздо меньшего размера, и они пока не вызывают серьезных проблем). Техническое обслуживание относительно простое, так как это в основном сгенерированный запрос, но сейчас я беспокоюсь о производительности. Мне интересно, сколько накладных расходов есть для всех этих выражений.

Чтобы увидеть, есть ли какая-либо разница, я написал другую версию этого запроса как:

select xmlelement("rootNode",
                   xmlforest(XH.ID, XH.SER_NUM,...

(я знаю, что этот запрос не производит точно то же самое, мой план состоял в том, чтобы переместить логику для обработки атрибутов переименования и xsi: nil в XSL или, возможно, в PL / SQL)

Я пытался получить планы выполнения для обеих версий, но они одинаковы. Я предполагаю, что логика не учитывается в плане выполнения. Моя интуиция говорит мне, что вторая версия должна выполняться быстрее, но я хотел бы доказать это (кроме написания тестовой функции PL / SQL с инструкциями синхронизации до и после запроса и повторного запуска этого кода, чтобы получить тестовый образец).

Можно ли получить хорошее представление о том, сколько будет стоить этот случай?

Кроме того, я мог бы написать case-при использовании функции декодирования. Будет ли это работать лучше (чем заявления случая)?

Answer 1

В целях настройки производительности вы имеете дело с этим утверждением:

SELECT *
FROM XH
WHERE XH.ID = 'SOMETHINGOROTHER' 

Как выполняется этот запрос?Если он возвращает значительно меньше времени, чем версия XML, вам нужно рассмотреть производительность функций, но я был бы удивлен, если бы это было так (ооо!).

Возвращает ли это одну или несколько строк?Если одна строка, то у вас есть только две вещи для работы:

• индексируется XH.ID и, если да, используется ли индекс?
• делает «еще много столбцов»из той же таблицы "указывает на проблему с связанными строками ?

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

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

Answer 2

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

Откройте свойства подключения и установите значение SET STATISTICS IO on. Проверьте, сколько чтений происходит. Посмотреть план запроса. Ваши индексы используются правильно? Вы знаете, как проанализировать план, чтобы увидеть?

Answer 3

Вы можете использовать старый добрый tkprof для анализа статистики. Одна из многих форм ALTER SESSION, которая включает сбор статистики. Пакет DBMS_PROFILER также собирает статистику, если ваш курсор находится в блоке кода PL / SQL.