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

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

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

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

Резюме

Без анализа в лоб огромных чисел, относящихся к планам выполнения, идеальная оптимизация запросов со многими таблицами лежит за пределами сегодняшнего состояния дел. Даже если будут сделаны определенные шаги вперед, идеальная оптимизация, вероятно, останется за пределами возможностей ручных методов настройки. Если вы решили зарабатывать на жизнь настройкой SQL-запросов, то без работы вы не останетесь. Проблема настройки SQL достаточно сложна, чтобы не удивляться такому положению дел. Но что действительно удивительно - так это тот факт, что, сосредоточившись на надежных планах вьтолнения и нескольких достаточно простых правилах, вы можете подойти вплотную к идеальной оптимизации для подавляющего большинства запросов. Локальная информация об узлах на диаграмме соединений, в частности, информация о коэффициентах фильтрации, оказывается вполне достаточной для выбора эффективного и надежного плана, не принимая во внимание его полную комбинаторную сложность.

Особые случаи

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

Внешние соединения

в каком-то смысле этот раздел принадлежит главе 6 или 7, так как во многих приложениях внешние соединения встречаются так же часто, как и внутренние. Действительно, в этих главах уже обсуждались некоторые проблемы, касающиеся внешних соединений. Однако некоторые вопросы о внешних соединениях логически исключаются из проблемы настройки SQL-запроса, а ответы на эти вопросы более понятны, если вы уже знакомы с аргументами, приведенными в главе 8. Таким образом, здесь я завершу обсуждение внешних соединений.

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

Я уже рассматривал несколько специальных вопросов относительно внешних соединений в главе 7 в соответствующих разделах.

Фильтрованные внешние соединения.

Внешние соединения, ведущие к внутренним соединениям.

Внешние соединения, указывающие на детальную таблицу.

Внешние соединения с представлениями.

Все эти случаи требуют особых средств решения, описанных в главе 7. Здесь я расширяю правила, данные в главе 7, чтобы суметь еще лучше оптимизировать

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

ОПРАВДАНИЕ ИСПОЛЬЗОВАНИЯ ВНЕШНИХ СОЕДИНЕНИЙ -

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

Так как я не вижу никаких затрат в правильно реализованных внешних соединениях, то задаю противоположный вопрос: Зачем использовать внутреннее соединение, если внешний случай внешнего соединения может быть полезен?

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

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

2 мое

0108 D2 D3 D4 D5 D8 D7

Рис. 9.1. Запрос с 16 неотфильтрованными внешними соединениями