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

 

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

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

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 92 93 94 95 96 97 < 98 > 99 100 101 102 103 104 .. 161 >> Следующая


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

Вложенные циклы выполняют 450 (3000 х 0,3 х 0,5) сканирований диапазонов для индекса по внешнему ключу, указывающему на М, и для этого требуется 350 (450 х 3) операций логического ввода-вывода в трехуровневом индексе. Затем последуют 2250 операций логического ввода-вывода для таблицы, чтобы считать 2250 строк из М. Так, общее количество операций логического ввода-вывода будет равно 3600 (1350 + 2250).
Сложный пример

197

Эти 3600 операций логического ввода-вывода, особенно 2250 для искомой таблицы, потребуют сотен операций физического ввода-вывода для такой большой, трудно кэшируемой таблицы. Если на одну операцию физического ввода-вывода потребуется 5-10 миллисекунд, то считывание из M займет секунды. Это пример типичного случая, когда соединения хэшированием выполняются лучше. В таких случаях улучшение обеспечивается обычно только в операциях логического вво-да-вывода для самых маленьких таблиц, и это улучшение очень невелико по сравнению со стоимостью оставшейся части запроса.

Две эмпирические формулы помогут вам выбрать лучший метод соединения:

H = CxR L=CxDxFxN

Переменные в этих формулах определяются следующим образом.

¦ H — количество операций логического ввода-вывода, необходимых для независимого считывания главной таблицы при выполнении соединения хэшированием.

¦ С — количество строк, возвращенных из главной таблицы.

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

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

¦ D — детальный коэффициент соединения для связи, которая ведет вверх от главной таблицы, и обычно указывает, насколько эта таблица меньше детальной таблицы наверху.

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

¦ N — количество операций логического ввода-вывода, необходимых для считывания одной строки через индекс по первичному ключу.

Так как первичные ключи до 300 строк обычно помещаются в корневой блок, то N = 2 (1 для корневого блока индекса и 1 для таблицы), если С меньше 300. N - 3, если С находится между 300 и 90 000. N - 4, если С между 90 000 и 27 000 000. Так как обычно вы будете начинать с наилучшего коэффициента фильтрации, то F < R, даже если план не обнаружит дополнительных фильтров после фильтра для ведущей таблицы.

H меньше L, что говорит в пользу соединения хэшированием для стоимости логического ввода-вывода, когда R<CxFxN. F<R, когда вы начинаете с узла с наилучшим коэффициентом фильтрации. N невелико, как показано, так как B-деревья на каждом уровне сильно разветвляются. Таким образом, чтобы выбрать соединение хэшированием, либо F по абсолютному значению должно быть близко к R, либо D велико, превращая это соединение в соединение с намного меньшей по размеру главной таблицей. Te же вычисления иногда будут демонстрировать эконо-
198

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

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

¦ Так как строки таблиц намного хуже кэшированы, чем блоки индекса, преимущество стоимости соединения хэшированием (если оно присутствует), когда стоимость физического ввода-вывода сильно доминирует, сравнимо с количеством строк таблицы, что ставит вопрос, верно ли, что R < D х F. Поскольку ввод-вывод для индекса намного лучше кэширован, чем ввод-вывод для таблицы, стоимость, определяемая физическим вводом-выводом, для считывания индексных блоков уменьшается в N раз. Без множителя N соединения хэшированием выглядят не настолько привлекательно.

¦ Если CxR велико, при соединении хэшированием может понадобиться записать предварительно хэшированные строки на диск и затем снова считать, что делает соединение хэшированием намного дороже и потенциально может привести к ошибкам недостатка дискового пространства во время выполнения запроса. Это риск надежности упомянутых вложенных циклов.

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

Однако это не подразумевает, что соединения хэшированием — ошибка. Стоимостные оптимизаторы ищут небольшие улучшения с таким же усердием, как и действительно существенные, и они успешно справляются с поиском случаев, в которых соединения хэшированием немного помогают. Хотя я практически никогда не ухожу с обычного пути, чтобы насильно включить соединение хэшированием, но я и не пытаюсь исправить выбор оптимизатора, если он выбирает такое соединение для небольшой таблицы (а он часто так делает), не портя при этом порядок соединения и выбор индексов. Если вы сомневаетесь, то всегда можете поставить эксперимент. Ho сначала найдите наилучший надежный план с вложенными циклами.
Предыдущая << 1 .. 92 93 94 95 96 97 < 98 > 99 100 101 102 103 104 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100