1. Используя условие Е. Last Name=?, перейти к индексу EMP LAST NAME и найти список идентификаторов строк, соответствующих сотрудникам с требуемой фамилией.

2. Для каждого из идентификаторов строки из предыдущего шага считать один блок (логическое считьшание, если требуется - физическое) из таблицы Empl oyees (Е), используя ту часть идентификатора, где хранится адрес блока. Используя ту часть идентификатора, где хранится адрес строки, найти определенную строку, на которую он указывает, и считать из нее все необходимые данные (запрошенные для псевдонима Е).

3. Для каждой такой строки, используя условие соединения Е. Location ID=LE. Locati on ID, перейти к индексу по первичному ключу LOCATION PKEY и найти единственный подходящий идентификатор строки, соответствующий записи о местоположении для того сотрудника, чью запись вы уже получили ранее. Если подходящей строки не найдено, отбросить результирующую строку, которая строится в данный момент.

4. В ином случае для каждого подходящего идентификатора строки из предыдущего шага необходимо вьшолнить считывание одного блока (логическое считывание, если требуется - физическое) из таблицы Locations (LE), используя ту часть идентификатора, где хранится адрес блока. Используя ту часть идентификатора строки, где хранится адрес строки, найти определенную строку, на которую указывает идентификатор, и считать из нее все необходимые данные (запрошенные для псевдонима LE). Присоединить подходящие данные к входящей строке, полученной при предыдущем считывании из таблицы, чтобы завершить результирующую строку. Отбросить всю результирующую строку, если она содержит данные, не отвечающие условию UCASECLE.Description) = ?.

ПРИМЕЧАНИЕ

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

Для всех возвращенных строк, объединяющих Е и LE, необходимо проделать еще несколько шагов.

Используя условие соединения E.Manager ID=M.Employee ID, перейти к индексу по первичному ключу EMPLOYEEPKEY и найти единственный подходящий идентификатор строки, соответствующий записи сотрудника, для менеджера того сотрудника, чью запись вы уже считали. Если подходящей строки не найдено, отбросить результирующую строку, которая строится в данный момент.

Иначе для подходящего идентификатора строки из предыдущего шага считать один блок (логические считывание, если требуется, физическое) из таблицы Empl oyees (М), используя ту часть идентификатора, где хранится адрес блока. Используя ту часть идентификатора строки, где хранится адрес строки, найти определенную строку, на которую указывает идентификатор, и считать из нее

13 record(s) selected.

OB20000I The Sa comiiand completed successfully. $

все необходимые данные (запрошенные для псевдонима М). Присоединить подходящие данные к входной строке, полученной при предыдущих считываниях из таблиц, чтобы создать частичную результирующую строку.

Для каждой такой строки, используя условие соединения М. Location ID=LM.Locati onID, перейти к индексу по первичному ключу LOCATION PKEY и найти единственный подходящий идентификатор строки, соответствующий записи о местоположении для менеджера того сотрудника, чью запись вы уже считали. Если подходящей строки не найдено, отбросить результирующую строку, которая строится в данный момент.

В ином случае для подходящего идентификатора строки из предьщущего шага считать один блок (логическое считывание, если требуется - физическое) из таблицы Locati ons (LM), используя ту часть идентификатора, где хранится адрес блока. Используя ту часть идентификатора, где хранится адрес строки, найти определенную строку, на которую указывает идентификатор, и считать из нее все необходимые данные (запрошенные для псевдонима LM). Присоединить подходящие данные ко входной строке, полученной при предьщущих считываниях из таблиц, чтобы завершить результирующую строку. Немедленно вернуть полностью построенную результирующую строку.

Ненадежные планы выполнения

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

$ cat head.sql tmp.sql tail.sql db2 +c +p -t OB20000I The SQL conmand completed successfully, DB20000I The SQL command completed successfully.

OPERATOR ID TARGET ID OPERATOR TYPE OBJECT NAME COST

В шагах с значением идентификатора OPERATORID с 5 по 11 сервер DB2 сортирует результаты полного сканирования таблиц Locations и Employees (псевдонимы LE и Е) по ключу соединения Location ID, отбрасывая строки, не удовлетворяющие фильтрующим условиям для этих таблиц. В шаге с 0PERAT0R ID=4 DB2 выполняет соединение сортировкой слиянием таблиц Е и LE. Интересно, что, видя такие хорошие фильтры для обеих таблиц, она решает, что на этом шаге останется максимум одна строка, и выбирает в качестве двух последних шагов вложенные циклы с полным сканированием таблиц для соединения псевдонимов М и LM. Вложенные циклы с полным сканированием таблиц, как в данном случае, будут работать плохо, если данные окажзтся такими, что DB2 придется пройти цикл слишком много раз. Стоимость соединения слиянием или хэшированием будет немного выше, чем у вложенных циклов с одним полным сканированием таблицы, но такие соединения на больших объемах работают лучше.

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

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

SELECT E.Firstjame. Е.Nickname. Е.Lastjame. Е.PhoneJumber. L.Description FROM Employees E

INNER JOIN Locations L ON E.Location ID=L.LocationJD WHERE (E.FirstJame= ? OR E.Nickname= ?) AND EXISTS (SELECT 1 FROM Wagejayments P

WHERE P.Employee ID=E.Employee ID

AND P.PaymentJate > CURRENT DATE - 31 DAYS);

Поместите в WagePayments 500 ООО строк. Создайте след}тощие индексы.

Empl oyees (Fi rstjame)

Employees(Nickname)

Locations(Location ID)

Wage Payments(Employee ID)

Тогда вы получите следующий план выполнения:

$ cat head.sql tmp.sql tail.sql db2 +c +p -t DB20000I The SOL command completed successfully. DB20000I The SQL command completed successfully.

OPERATOR ID TARGET ID OPERATORJYPE OBJECTJAME COST

1 - RETURN - 2014

2 1 MSJOIN - 2014

3 2 TBSCAN - 203

4 3 SORT - 203

5 4 TBSCAN LOCATIONS 202