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

 

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

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

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


¦ Значения детальных коэффициентов соединения велики, намного больше 1,0. Так как главные коэффициенты соединения (вниз по дереву соединения) никогда не превышают 1,0, будет гораздо безопаснее, если вы произведете как можно больше соединений вниз перед переходом к соединениям в верхнем направлении, даже если во втором случае вы получаете доступ к большему количеству фильтров. Обычно фильтры для узлов, расположенных в верхней части дерева, отбрасывают не больше строк, чем база данных выбирает, переходя к более детальной таблице. Даже когда детальные коэффициенты соединения невелики, сама природа соединения «один ко многим», обеспечивает вероятность того, что эти значения могут существенно возрасти в будущем или на других машинах, где выполняется то же самое приложение. Поэтому для большого коэффициента детализированного соединения лучше выбирать надежный SQL-код, кроме тех случаев, когда вы полностью уверены, что локальная, текущая статистика не изменится со временем и будет одинакова для различных наборов данных.

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

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

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

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

¦ Когда таблицы достаточно велики, чтобы эффективность имела большое значение, то существует один коэффициент фильтрации, намного меньший всех остальных. Редко встречаются две таблицы с практически одинаковым коэффициентом фильтрации. Если таблицы велики, а результат выполнения запроса относительно мал, как обычно бывает с полезными результатами запросов, то произведение всех коэффициентов фильтрации должно быть небольшим. Гораздо проще получить этот небольшой результат при помощи одного селективного фильтра, иногда в сочетании с несколькими достаточно не селективными фильтрами, чем при помощи большого количества схожих полуселек-тивных фильтров. Поиск разумных (в терминах ведения бизнеса) объяснений большому количеству полуселективных фильтров оказывается неблагодарным делом, и я мог бы сосчитать количество раз, когда встречался с подобными случаями за 10 лет настройки SQL, по пальцам одной руки. Имея один фильтр, обладающий намного большей селективностью, чем остальные, гарантировать считывание минимального количества строк из самой важной корневой детальной таблицы можно, если начать выполнение запроса с таблицы с наилучшим фильтром.

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

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

Безопасные декартовы произведения

Рассмотрим запрос, диаграмма для которого показана на рис. 6.14. Выполняя обычные правила (и выбирая первым самый левый узел, просто для удобства), мы переходим к фильтру для Tl и присоединяем Tl к M1 используя индекс по внешнему ключу, указывающему на Tl. Затем мы переходим к Т2, используя индекс по первичному ключу, и в конце отбрасываем строки, не проходящие
Сложный пример

177

через фильтр для Т2. Если предположить, что в Tl 100 строк, то, на основании коэффициентов соединения, в M должно быть 100 ООО строк, и в Т2 — также 100 строк.

M

Tl O1OI Т2 OOI

Рис 6.14. Запрос с потенциально хорошим планом выполнения с декартовым произведением

Описанный план затронет 1 строку в Tl, 1000 строк в M (1 % от общего количества) и 1000 строк в Т2 (в среднем каждая строка из Т2 нужна 10 раз) перед тем, как отбросить из результата все строки, оставив лишь 10. Если аппроксимировать стоимость запроса как количество полученных из таблиц строк, то она составит 2001. Однако если пойти против правил, то можно получить план, который не следует связям, обозначающим соединения. Можно выполнить вложенные циклы между Tl и Т2, используя соответствующие фильтрующие индексы. Поскольку между Tl и Т2 нет соединения, в результате мы получим декартово произведение всех строк, удовлетворяющих условию фильтрации для Tl и всех строк, удовлетворяющих условию фильтрации для Т2. Для данных размеров таблиц результирующий план выполнения считает лишь по одной строке из Tl и Т2. Выполнив декартово соединение Tl и Т2, база данных сможет использовать индекс по внешнему ключу, которые указывает на Tl, чтобы перейти к M и считать из нее 1000 строк. Затем база данных отбросит 990 строк, не удовлетворяющих условию соединения для M и Т2.
Предыдущая << 1 .. 82 83 84 85 86 87 < 88 > 89 90 91 92 93 94 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100