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

 

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

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

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


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

Случаи, когда нужно выбрать соединения хэшированием

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

Если вы начинаете с таблицы, отфильтрованной лучше остальных в запросе, любое соединение вверх, от главной к детальной таблице, унаследует селективность ведущего фильтра и всех остальных фильтров, которые встретятся к этому моменту в порядке соединения. Например, рассмотрим рис. 6.32. Следуя обычным правилам, начните с Al с коэффициентом фильтрации 0,001, и выполните два соединения вниз, используя остальные фильтры, равные 0,3 и 0,5, для BI и В2, соответственно. Следующее соединение с детальной таблицей, М, обычно происходит через индекс по внешнему ключу, который указывает на Al, причем доля нужных строк составит 0,00015 (0,001 х 0,3 х 0,5). Если детальная таблица достаточно большая, чтобы иметь значение для работы приложения, а запрос не возвращает большого количества строк, эта стратегия практически гарантирует, что вложенные циклы по внешним ключам по направлению к детальным таблицам будут наилучшим выбором. Другие методы соединения, например соединение хэшированием, которое обращается к детальной таблице независимо, через собственный фильтр, считают большую долю строк той же таблицы, так как лучший вариант (с вложенными циклами) начинает работу с лучшего коэффициента фильтрации в запросе.

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

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

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

м

Рис. 6.32. Иллюстрация запроса, требующего соединений хэшированием

С другой стороны, когда вы выполняете соединение вниз по направлению к главной таблице, то это может быть соединение с намного меньшей таблицей, и стоимость получения строк через первичный ключ может быть больше, чем стоимость независимого считывания таблицы для соединения хэшированием. Из статистики на рис. 6.32 можно узнать, что в Al в 3000 раз больше строк, чем в BI. Даже отбросив 999 строк из 1000 из Al, база данных выполнит соединение с каждой строкой из BI в среднем три раза. Предположим, что в Al 3 000 000 строк, а в BI 1000 строк. После уменьшения Al до 3000 строк с использованием ведущего фильтра база данных выполнит соединения со строками таблицы BI 3 000 раз. Если база данных будет считывать BI через ее собственный фильтр, ей понадобится считать лишь 300 (0,3 х 1000) строк, по приблизительно 1/10 стоимости. Так как запрос получает более 20 % строк из BI, база данных обнаружит даже меньшую стоимость, просто выполнив полное сканирование таблицы BI и отфильтровав результат перед выполнением соединения хэшированием. Таким образом, не изменяя оставшуюся часть стоимости, выбор соединения хэшированием с BI практически полностью устранит стоимость считывания из таблицы BI по сравнению со стандартным надежным планом, который считывает BI через вложенные циклы.

Когда вы встречаете большие детальные коэффициенты соединения, соединения хэшированием с главными таблицами могут оказаться быстрее. Ho насколько велико улучшение? В этом примере частичное улучшение для одной таблицы было достаточно большим, более 90 %, но абсолютное улучшение не столь значительно, приблизительно 9000 операций логического ввода-вывода (6000 в двухуровневом ключевом индексе и 3000 в таблице), что займет приблизительно 150 миллисекунд. Вы не найдете никаких операций физического ввода вывода для таблицы и индекса такого размера. С другой стороны, этот запрос считает приблизительно 2 250 строк (3000 х 0,3 х 0,5 х 5) из 15 000 000-строчной таблицы М, выполнив 3600 операций логического ввода-вывода.
Предыдущая << 1 .. 91 92 93 94 95 96 < 97 > 98 99 100 101 102 103 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100