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

 

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

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

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 80 81 82 83 84 85 < 86 > 87 88 89 90 91 92 .. 161 >> Следующая

Для подобного необычного случая два соединения с M действительно дешевле одного! Обратите внимание на две подсказки в этом варианте запроса.

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

¦ Выражение INDEX (MI M_DoubleKeyInd) гарантирует использование правильного индекса в той точке порядка соединения, где вам требуется только доступ к индексу MI.

Для правильного выполнения оставшейся части плана могут потребоваться другие подсказки. Также обратите внимание на необычное соединение «идентификатор строки с идентификатором строки» между MI и MT, и что единственные ссылки на MI есть только в разделе FROM и в условиях раздела WHERE. Для этих ссылок требуются только данные (два внешних ключа и идентификатор строки), хранящиеся в индексе. Это очень важно — Oracle не переходит к таблице M сразу же после того, как считывает индекс по первичному ключу M только потому, что MI обращается только к индексированным столбцам и идентификаторам строки, которые также хранятся в индексе. Все столбцы в операторе SELECT и везде в условиях раздела WHERE (например, соединение с АЗ, которое не показано) получены из MT. Поэтому оптимизатор считает, что все столбцы, необходимые для MI, уже находятся в индексе. Он считает это соединение исключительно индексным. Прямое соединение с MT по ROWID выполняется позже в порядке соединения, и все столбцы таблицы M выбираются из MT.

Однако только что описанный мной метод используется очень редко по нескольким причинам.

¦ Комбинированные индексы из двух необходимых вам внешних ключей в правильном порядке встречаются редко.

¦ Обычно корневая детальная таблица не увеличивает стоимость настолько, в относительных и абсолютных единицах, чтобы оправдать старания.

¦ Выгоды редко оправдывают создание нового многостолбцового индекса, если он еще не существует.

Решение специфичной проблемы для других серверов

Если в разделе WHERE вы не можете указывать напрямую идентификаторы строк, может ли этот трюк сработать в той же форме? Единственная часть настройки, которая зависит от идентификаторов строк, — это соединение между MI и MT. Эти псевдонимы таблиц также можно соединить по полному первичному ключу. Стой-
Сложный пример

171

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

Сложный пример

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

M 0.001

Al 0.3 А2 0.7 АЗ 0.5

BI 0.6 В2 ВЗ В4 0.1 В50.75

Cl 0.6 С2 0.8 СЗ С4 0.8 С5 0.2 С6 0.9

D10J5 D20?

Рис. 6.9. Другая задача с тем же скелетом соединения

Это довольно распространенный случай, когда наилучший фильтр накладывается на корневую детальную таблицу.

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

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

6. Выбор наилучшего плана выполнения

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

Первые допустимые узлы — это Al, А2 и АЗ, а лучший коэффициент фильтрации относится к Al, поэтому вторым в порядок соединения мы помещаем узел Al. После расширения облака на Al в список допустимых узлов добавляются узлы BI и В2, причем А2 и АЗ также остаются допустимыми. Среди этих четырех узлов у АЗ наилучший коэффициент фильтрации, поэтому его мы присоединяем следующим. Итак, на данный момент порядок соединения (М. Al. АЗ), а облако соединения выглядит как на рис. 6.10.
Предыдущая << 1 .. 80 81 82 83 84 85 < 86 > 87 88 89 90 91 92 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100