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

 

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

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

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 32 33 34 35 36 37 < 38 > 39 40 41 42 43 44 .. 161 >> Следующая


PLAN

SELECT STATEMENT MERGE JOIN SORT JOIN MERGE JOIN SORT JOIN MERGE JOIN SORT JOIN TABLE ACCESS FULL 4*EMPL0YEES SORT JOIN TABLE ACCESS FULL 3*EMPL0YEES SORT JOIN TABLE ACCESS FULL 2*L0CATI0NS SORT JOIN TABLE ACCESS FULL 1*L0CATI0NS

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

Соединения хэшированием более распространены в критичных к ресурсам планах выполнения, чем соединения слиянием, и иногда вы даже будете предпочитать их соединениям методом вложенных циклов, поэтому далее я привожу пример с соединением подобного типа. Обратите внимание, что в исходном SQL-запросе, для которого был создан предыдущий план, сразу же за ключевым словом SELECT есть выражение /*+ RULE */. Если я заменю выражение /*+ RULE */ выражением / *+0RDERED USЕ_НASH(M LE LM) */ и изменю порядок в разделе FROM, то с пустыми таб-
76

3. Просмотр и интерпретация планов выполнения

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

PLAN

SELECT STATEMENT HASH JOIN HASH JOIN HASH JOIN TABLE ACCESS FULL 1*EMPL0YEES TABLE ACCESS FULL 2*EMPL0YEES TABLE ACCESS FULL 3*L0CATI0NS TABLE ACCESS FULL 4*L0CATI0NS

Этот план выполнения идентичен предыдущему, HO он заменяет соединения слиянием соединениями хэшированием.

Сложные планы выполнения

Существуют и другие свойства планов выполнения, например, индикаторы, указывающие, какие из соединений являются внешними, перечисление шагов сортировки и операторов, обеспечивающих уникальность сортировки, которые удаляют дублирующиеся значения. С ними вы будете встречаться часто, но их назначение интуитивно понятно и они не столь важны для производительности. Однако есть и важные для нас тонкости, с которыми вы также часто будете иметь дело. Они относятся к подзапросам и составным планам выполнения. Я продемонстрирую их в одном примере SQL-запроса:

SELECT /*+ RULE */ E.First_Name. Е.Nickname. E.Last_Name.

E.Phone_Number. L.Description FROM Employees E. Locations L WHERE (E.First_Name='Kathy' OR E.Nickname='Kathy')

AND E.Location_ID=L.Location_ID AND EXISTS (SELECT null

FROM Wage_Payments P WHERE P.Employee_ID=E.Employee_ID AND P.Payment_Date > sysdate-31):

Создадим несколько индексов.

¦ EiTipI oyees (Fi rst_Name)

¦ Employees(Nickname)

¦ Locations(Location_ID)

¦ Wage_Payments(Employee_IO)

Теперь мы получим соответствующий план выполнения:

PLAN

SELECT STATEMENT CONCATENATION FILTER NESTED LOOPS TABLE ACCESS BY INDEX ROWID 1*EMPL0YEES INDEX RANGE SCAN EMPLOYEE_NICKNAME TABLE ACCESS BY INDEX ROWID 2*LOCATIONS INDEX UNIQUE SCAN L0CATI0N_PKEY TABLE ACCESS BY INDEX ROWID 3*WAGE_PAYMENTS
Чтение планов выполнения в DB2

77

INDEX RANGE SCAN WAGE_PAYMENT_EMPLOYEE_ID FILTER NESTED LTOPS TABLE ACCESS BY INDEX ROWID 1*EMPL0YEES INDEX RANGE SCAN EMPLOYEE_FIRST_NAME TABLE ACCESS BY INDEX ROWID 2*L0CATI0NS INDEX UNIQUE SCAN LOCATION_PKEY

Шаг CONCATENATION указывает, что оптимизатор реализовал запрос как неявный оператор UNION для двух различных запросов (это существенно), один из которых получает данные при помощи индекса Fi rst_Name, а второй — при помощи индекса по полю Nickname. После выполнения внешнего запроса шаг FILTER реализует корреляционное соединение по условию P.Employee_ID=E.Employee_ID, переходя при помощи индекса по внешнему ключу из Wage_Payments в Empl oyees. Шаг FILTER — это в действительности то же самое, что и соединение со вложенными циклами, за исключением того, что он останавливается после появления первой подходящей строки, если она существует. Обратите внимание, что второй шаг FILTER обращается к тому же корреляционному соединению с Wage Payments1 что и первый шаг Wage_Payments. Это особенность сцепленного плана выполнения, который повторяет во внешнем запросе шаги соединений, но не шаги корреляционного соединения.

Чтение планов выполнения в DB2

В DB2 применяется несколько подходов к созданию и отображению планов выполнения. SQL-запрос используется для помещения данных в таблицу, после чего данные можно просмотреть несколькими способами. Вот основные методы, которые компания IBM сама описывает в документации.

¦ Visual Explain. Для Visual Explain требуется инсталляция этой утилиты на рабочей станции клиента, и эта возможность доступна не на всех поддерживаемых платформах. Поэтому я никогда не использовал Visual Explain. Я предпочитаю работать с инструментом, который будет доступен всегда и везде.

¦ Утилита db2exfmt. Эту утилиту можно запустить из командной строки в любой среде, в том числе неграфической, поэтому вы всегда можете рассчитывать на нее. Однако я обнаружил, что она сообщает мне гораздо больше, чем я хочу знать, поэтому иногда работать становится слишком трудно и неудобно. Например, она выдала отчет длиной 1216 строк по плану выполнения для простого четырехстороннего соединения. Трудно использовать даже ту часть отчета, которая представляет суть плана выполнения. Дерево плана выполнения отображается в символах ASCII с имитацией графического представления структуры дерева, но для его просмотра, кроме случаев простейших планов выполнения, требуется намного большая длина строки, чем человек может легко воспринять.
Предыдущая << 1 .. 32 33 34 35 36 37 < 38 > 39 40 41 42 43 44 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100