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

 

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

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

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


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

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

Особый случай

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

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

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

Решение для Oracle

Вернитесь к рис. 6.4 и представьте, что все таблицы кроме M относительно невелики и хорошо кэшированы, a M — очень большая и поэтому плохо кэширована, и доступ к ней существенно дороже, чем к остальным таблицам. Кроме того, M — это особенная таблица комбинаций, выражающая отношение «многие ко многим» меж-
Особый случай

169

ду Al и А2. Примером такой таблицы комбинаций может быть таблица, содержащая сочетания актер-фильм для базы данных об истории кинематографа, связывающая таблицы Movies и Actors, отношения между которыми принадлежат виду «многие ко многим». В такой таблице комбинаций естественно использовать первичный ключ, состоящий из двух частей, то есть из идентификаторов связанных таблиц — в нашем случае Movi e_ID и Actor_ID. Как это часто бывает, у таблицы комбинаций есть индекс по комбинации внешних ключей, указывающих на таблицы А2 и Al. Для нашего примера предположим, что порядок ключей в индексе таков: сначала внешний ключ, указывающий на А2, затем внешний ключ, указывающий на Al.

Рассмотрим стоимость доступа к каждой таблице в том плане, который я составил ранее, считая его решением для рис. 6.4. Можно найти низкую стоимость доступа для таблиц под М, затем намного большую стоимость доступа к М, так как вы получаете существенно больше строк из этой таблицы, чем из предыдущих, и доступ к этим строкам требует операций физического ввода-вывода. После обработки M база данных присоединяет такое же количество строк из Al (так как для M нет фильтра), но стоимость каждой такой строки гораздо меньше, поскольку они полностью кэшированы. Затем фильтр в Al сбрасывает количество строк обратно до небольшого количества для оставшихся в плане таблиц. Таким образом, стоимость практически полностью определяется стоимостью доступа к М, поэтому полезно было бы снизить именно эту составляющую.

Как это случается в подобных необычных случаях, вы находите возможность обойти внешний ключ в М, указывающий на А2, и перейти к указывающему на Al внешнему ключу, который хранится в том же многостолбцовом индексе в М, даже не обращаясь к таблице М. Позже базе данных потребуется считать строки из самой таблицы М, чтобы получить внешний ключ, указывающий на АЗ и, возможно, считать столбцы из списка SELECT запроса. Однако вы можете отложить обращение к этой таблице до того момента, как база данных пройдет фильтрованные таблицы Al и Cl. Таким образом, базе данных потребуется получить только 18 % тех строк из M (0,3 х 0,6, учитывая коэффициенты фильтрации 0,3 для Al и 0,6 для Cl), которые потребовалось бы считать, если бы база данных перешла к таблице M сразу же после обращения к индексу для М. Это существенно снижает стоимость запроса, так как стоимость считывания строк из таблицы M преобладает в данном специфическом случае.

Ни в одной базе данных разъединение считываний из индекса и считываний из таблицы не дается легко. Считывание из таблицы обычно автоматически следует сразу же за считыванием из индекса, даже если это не оптимально. Ho Oracle позволяет выполнить фокус, решающий эту проблему, так как в SQL в Oracle можно явно указывать идентификаторы строк. В данном случае наилучший порядок соединения - (В4. С5, С4. А2, ВЗ. С2. СЗ. Dl, D2. MI. Al. BI. Cl, MT. АЗ. В5. Сб, В2).Здесь MI — это индекс по M(FkeyТоА2, FkeyToAl), который в порядке соединения находится на исходном месте М. MT — это таблица М, доступ к которой производится по плану позже через ROWID из MI. MT вставлена в порядок соединения после обработки фильтров для Al и Cl. Трюк заключается в том, чтобы обратиться к таблице M дважды в разделе FROM, один раз только для доступа к индексу и один раз для прямого соединения по R0WID, как показано далее. Имя индекса M(FkeyToA2.FkeyToAl) — это M_DoubleKeyInd:
170

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

Select /*+ ORDERED INDEX(MI MJtoubleKey Ind) */ MT.Coll. МТ.С0І2....

FROM B4. C5. CA. A2. B3. C2. C3. Dl. D2.

M MI. Al. BI. Cl. M MT. АЗ. B5. Сб. B2 WHERE ...

AND A2.Pkey=MI.FKeyToA2 AND Al.Pkey=MI.FKeyToAl AND MI.ROWID=MT.ROWID AND...

Предыдущая << 1 .. 79 80 81 82 83 84 < 85 > 86 87 88 89 90 91 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100