0

При создании и настройке запроса в Oracle скорость, как правило, является основной задачей для разработчика. Однако при настройке определенного запроса я недавно попробовал FIRST_ROWS и NO_CPU_COSTING намеки, и был составлен план выполнения, который на 80% быстрее, чем предыдущий план во время исполнения, но при более высокой цене на 300%. В плане выполнения очень мало ввода-вывода, и кажется, что все дополнительные затраты связаны с внешним соединением вложенного цикла между двумя представлениями.Стоимость плана исполнения Oracle по сравнению с скоростью

Этот запрос разбит на страницы, поэтому мне понадобятся только первые несколько строк. Отсутствие значительного ввода-вывода приводит меня к мысли, что этот запрос не будет зависящим от кэша, и на первый взгляд кажется, что это путь. Однако, поскольку я никогда не видел увеличения запроса в скорости и, так дорого стоить в то же время, я не уверен, какими могут быть недостатки в использовании этого запроса. Есть ли какие-нибудь?

+0

два намека, которые вы упомянули, очень ориентированы на вложенный цикл - NL полезна для извлечения первых N строк, и это довольно простой подход для очень дешевого процессора. альтернативой является сортировка слияния, например, в основном используется для объединения двух больших таблиц. это дорогостоящий процессор, потому что он требует своего рода. хеш-соединение также дорогостоящее CPU, потому что оно требует применения хэш-функции. я не знаю конкретно о вашем случае, но большинство систем связаны с диском, а не с ЦП, поэтому уменьшение количества считываемых дисков приводит к снижению стоимости. – haki

+0

На самом деле, я считаю, что точность важнее скорости. –

+0

Я работал над системами с более чем 500 000 строк в таблице. Я думаю, что скорость является обязательной или может повредить всю систему. –

ответ

4

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

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

Тем не менее, в оценочной стоимости нет ничего неправильного, это именно то, что есть. Если вы хотите получить более значимую цифру для своего собственного понимания, используйте лимит rownum.

Кстати, FIRST_ROWS устарел в пользу first_rows (1), first_rows (10), first_rows (100) или first_rows (1000).

+0

Вы правы! По-видимому, это не появилось на странице Oracle, на которую я смотрел, но подсказка FIRST_ROWS действительно устарела. Однако вы указываете параметр OPTIMIZER_MODE. Совет FIRST_ROWS устарел в пользу FIRST_ROWS (n). Я переключился на FIRST_ROWS (1), и план показал более разумную стоимость. Если вы обновите свой ответ, я соглашусь с ним :) – monitorjbl

Смежные вопросы