Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 60

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 54 55 56 57 58 59 < 60 > 61 62 63 64 65 66 .. 161 >> Следующая


ВНИМАНИЕ -------------------------------------------------------------------------------------

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

Существует несколько других подсказок для доступа к таблицам, которые я не привел в этом разделе, но я никогда не сталкивался со случаями, когда они были бы полезны.

Подсказки для порядка выполнения запроса

Далее перечислены основные подсказки для управления порядком выполнения соединений и подзапросов.

¦ ORDERED. Рекомендует Oracle, когда возможно, соединять таблицы в том порядке, в каком они перечислены во фразе FROM.

ПРИМЕЧАНИЕ -----------------------------------------------------------------

Эта подсказка, в отличие от остальных, обычно требует изменения тела SQL-запроса (или, по крайней мере, раздела FROM) для получения желаемого плана, так как она относится к порядку выполнения FROM. Обратите внимание, что желаемый порядок перечисления таблиц в разделе FROM будет в точности противоположным наилучшему порядку раздела FROM, который вы бы выбрали для синтаксической оптимизации. Это происходит потому, что RBO работает справа налево, в то время как подсказка заставляет CBO выполнять FROM слева направо.

¦ LEADING (<Имя_псевдонимд>). Если подсказка ORDERED не указана, то выбирается ведущая таблица, то есть первая таблица в порядке соединения. Хотя в данном случае вы в меньшей степени контролируете порядок выполнения, чем с подсказкой ORDERED, вам зато не требуется изменять раздел FROM. Часто один лишь выбор правильной ведущей таблицы — это все, что требуется для получения производительности, близкой к оптимальной. Последующий порядок соединения значит меньше и, вероятнее всего, будет удачно выбран оптимизатором без вашей помощи.

¦ PUSH_SUBQ. Эта подсказка приказывает оптимизатору выполнять коррелированные подзапросы, как только это возможно — как только внешний запрос достигнет столбцов соединения, необходимых для оценки подзапросов. Обычно
Управление планами в Oracle

119

CBO в Oracle выполняет коррелированные подзапросы только после завершения всех соединений во внешнем запросе.

Подсказки ORDERED и LEADING часто встречаются и их легко использовать. Иногда бывает полезной подсказка PUSH_SUBQ.

Когда дело доходит до подзапросов, Oracle предлагает управление на основе подсказок только для двух крайних случаев — выполнение подзапросов как можно раньше и как можно позже. Однако вы сможете полностью контролировать момент выполнения подзапросов, если примените подсказку PUSH SUBQ вместе с методами, позволяющими откладывать коррелированные соединения, описанными ранее. Например, рассмотрим запрос:

SELECT ...

FROM Orders 0. Customers С. Regions R WHERE O.Status_Code='OP'

AND O.Customer_ID=C.Customer_ID AND C.CustomerJTypeJode-'GOV'

AND C.Region_ID=R.Region_ID AND EXISTS (SELECT NULL

FRDM Order_Details OD

WHERE 0.Drder_ID+0*C.Customer_ID=DD.Order_ID AND OD.Shipped_Flag="V")

Без подсказки Oracle выполняет проверку EXISTS после соединения всех трех таблиц во внешнем запросе. Смысл выражения 0.0rder_ID+0*C.Customer_ID заключается в том, чтобы отложить проверку EXISTS и выполнить ее только после присоединения С, но перед присоединением R. В случае, когда нет никаких подсказок, все условия EXISTS автоматически откладываются, пока не будут выполнены все соединения во внешнем запросе. Чтобы заставить условие EXISTS выполняться между присоединением С и R, используйте и подсказку, и выражение, позволяющее отложить коррелированное соединение:

SELECT /*+ PUSHSUBQ *1 ...

FROM Orders 0. Customers С. Regions R WHERE O.Status_Code='DP'

AND O.Customer_ID=C.Customer_ID AND C.CustomerJTypeJode^'GOV'

AND C.Region_ID=R.Region_ID AND EXISTS (SELECT NULL

FROM 0rder_Details OD

WHERE 0.0rder_ID+0*C.Customer_ID=OD.0rder_ID AND DD.ShippedJlag='Y')

Теперь подсказка PUSH_SUBQ заставляет Oracle выполнять условие EXISTS как можно раньше, а выражение 0.0rder_ID+0*C.Customer_ID гарантирует, что этот момент не наступит, пока не будет выполнено соединение с С.

Подсказки для методов соединения

Далее перечислены основные подсказки для управления методами соединения.

¦ USEJIL (Список_псевдонтов>). Рекомендует Oracle соединять таблицы, перечисленные в списке псевдонимов, используя вложенные циклы. Псевдонимы в списке не должны разделяться запятыми, например, USE_NL(T1 Т2 ТЗ).

¦ USE_HASH (<Список_псевдонинов>). Предлагает серверу соединять таблицы, перечисленные в списке псевдонимов, используя хэширование. Псевдонимы в списке не должны разделяться запятыми, например USE HASHCTl Т2 ТЗ).
Предыдущая << 1 .. 54 55 56 57 58 59 < 60 > 61 62 63 64 65 66 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100