Поскольку проверка селективных условий NOT EXISTS недорога, оказывается, вычислить уточненный коэффициент фильтрации подзапроса легко.

1. Измерьте q (количество строк, возвращенных внешним запросом, если удалить условие подзапроса NOT EXISTS) и t (количество строк, возвращенное полным запросом, включая подзапрос). Пусть С - количество таблиц в разделе FROM подзапроса (обьгано для условий NOT EXISTS это число равно единице).

2. Пусть уточненный коэффициент фильтрации подзапроса равен (С - 1 + (t/q))/C.

Настройка запросов с подзапросами

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

1. Преобразуйте все условия NOT IN в эквивалентные условия NOT EXISTS следуя описанному ранее шаблону.

2. Если корреляционное соединение - это соединение типа EXISTS, и подзапрос находится на главном конце этого соединения (то есть указатель стрелки посередине связи указывает вниз), преобразуйте сложный запрос в простой, как описано ранее, и настройте его, следуя обьганым правилам для простых запросов.

3. Иначе, если корреляционное соединение - это соединение типа EXISTS, найдите наименьший корреляционный коэффициент предпочтения среди всех подзапросов типа EXISTS (если их больше одного). Если значение этого коэффициента меньше 1,0, преобразуйте это условие подзапроса в эквивалентное условие IN и выразите все остальные условия подзапросов типа EXISTS, явно применяя условие EXISTS. Оптимизируйте некоррелированный подзапрос IN, как если бы это был отдельный запрос; это начало плана исполнения всего запроса. После обработки некоррелированного подзапроса база данных выполнит операцию сортировки, чтобы выбросить повторяющиеся ключи коррелированного соединения из списка, созданного подзапросом. Следующее соединение после обработки этого первого подзапроса выполняется с коррелированным ключом во внешнем запросе, следуя индексу по этому ключу соединения, который должен быть индексирован. Начиная с этой точки, обрабатывайте внешний запрос, как если бы ведущий подзапрос не существовал, а первым узлом была бы ведущая таблица внешнего запроса.

4. Если все корреляционные коэффициенты предпочтения больше или равны 1,0 или если в запросе есть только условия подзапросов типа NOT EXISTS, выберите ведущую таблицу из внешнего запроса, как если бы в нем не было условий подзапроса, следуя обычным правилам для простых запросов.

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

ПРИМЕЧАНИЕ

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

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

В качестве примера возьмем рис. 7.32, представляющий собой рис. 7.31 с указанными корреляционным коэффициентом предпочтения и уточненным коэффициентом фильтрации подзапроса.

D0.1

2,0..;

А10.2 А2 0.7

6108 В2

Рис. 7.32. Задача на оптимизацию сложного запроса с подзапросом

Так как коррелированное соединение относится к типу EXISTS, шаг 1 не применяется. Так как указатель стрелки посередине полу соединения указывает вверх, шаг 2 не применяется. Самый маленький (и единственный) корреляционный коэффициент предпочтения равен 1,5 (рядом с Е), поэтому шаг 3 не применяется. Выполняя шаг 4, находим, что наилучший ведущий узел во внешнем запросе - это М. Выполняя шаг 5, выбираем между соединениями вниз с А1 и А2 с коэффициентами фильтрации 0,2 и 0,7, соответственно, и виртуальным соединением вниз с виртуальным узлом, представляющим полный подзапрос, с виртуальным коэффициентом фильтрации 0,6. А1 - лучший из этих трех кандидатов, имеюший лучший коэффициент фильтрации, поэтому присоединяем его следующим. Так как от А1 нет соединений вниз, следующим лучшим выбором в порядке соединения считаем подзапрос (опять применяя шаг 5), поэтому выполняем полусоединение с D.

Выполняя шаг 6, уже начав обработку подзапроса, необходимо закончить его, начиная с D как с ведущего узла. Следуя правилам для простых запросов, далее присоединяем S1, S3, S2 и S4 в указанном порядке. Возвращаясь к внешнему запросу и применяя обычные правила для простых запросов, находим оставшийся по-

рядок соединения как А2, В1, В2. Полный оптимальный порядок соединения, включая полусоединение - (М. А1. D. S1. S3. S2. 34. А2. В1. В2).

ПОЧЕМУ НЕОБХОДИМО ТАК БЕСПОКОИТЬСЯ О ПОДЗАПРОСАХ?-

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

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

Запросы с представлениями

Используя представления, можно сделать так, чтобы чрезвычайно сложный запрос выглядел как простая таблица с точки зрения человека, который пишет запрос с использованием представления. Когда множество запросов совместно используют большое количество базового SQL-кода, то общие представления многократного использования могут стать мощным механизмом для упрощения кода приложения. К сожалению, простое сокрытие действий от разработчика приложения не уменьшает сложность этих действий, предназначенных для пол5Д1ения фактических данных. С другой стороны, сокрытие сложности от разработчика с большой вероятностью усложнит проблему настройки, которую оптимизатору придется преодолеть в поиске быстрого плана исполнения. В этом разделе я упоминаю два типа запросов, значимых для проблемы настройки.

L Запросы, определяющие представления.

Это запросы, лежащие в основе представлений (то есть запросы, которые применяются для создания представлений при помощи CREATE VIEW <Ф1мя представле-ния> AS <Запрос опрвделяющий представление>).

2. Запросы, использующие представления.

Это запросы, которые вы настраиваете, и которые база данных фактически выполняет. В этих запросах представления упоминаются во фразе FROM (например, SELECT ... FROM Viewl VI, View2 V2,... WHERE ...).

При настройке SQL представления обычно добавляют сложности в трех отношениях.

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