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

 

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

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

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 119 120 121 122 123 124 < 125 > 126 127 128 129 130 131 .. 161 >> Следующая

Почему метод диаграмм работает

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

Аргументы в пользу вложенных циклов

На протяжении всей книги я утверждаю, что соединения методом вложенных циклов по ключам соединения обеспечивают более надежные планы выполнения, чем соединения хэшированием или сортировкой слиянием. Давайте посмотрим, почему это именно так. Рассмотрим диаграмму запроса с двумя таблицами, показанную на рис. 8.1.

AFa

Jd>1

Jm=I

Ў

BFb

Рис 8.1. Тестовый запрос с двумя таблицами

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

¦ Верхняя таблица в диаграмме велика или же ожидается ее большое увеличение. Так Kai<Jd, детальный коэффициент соединения, больше 1,0, нижняя таблица меньше верхней в несколько раз, причем число, равное отношению между ними, может быть средним или большим. Чаще всего встречаются запросы, счи-
254

8. Почему метод диаграмм работает

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

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

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

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

¦ Количество строк, которое вернет запрос, равно Ca х Fa х Fb, где Ca — это количество строк, возвращенное иэ таблицы А.

Эти утверждения ведут к заключению, что произведение двух коэффициентов фильтрации (Fa х Fb) должно быть небольшим, и со временем уменьшаться. Таким образом, по крайней мере, одно из значений Fa или Fb также должно быть небольшим. На практике это практически всегда достигается за счет того, что один из коэффициентов фильтрации намного меньше другого. Меньшим коэффициентом фильтрации обычно является именно тот коэффициент, который со временем монотонно уменьшается. В целом, наименьший из этих коэффициентов фильтрации оправдывает индексный доступ при выборе между ним и полным сканированием таблицы.

Если лучший (наименьший) коэффициент фильтрации — это Fb и он достаточно мал, чтобы оправдать индексный доступ к таблице В, то вложенные циклы от В в общем случае будут указывать на такую же часть (Fb) строк таблицы А. Данное количество главных записей будет указывать на такую же долю детализированных строк. Эта доля также будет достаточно небольшой, чтобы оправдать индексный доступ (в данном случае через внешний ключ) к таблице А, причем его стоимость будет меньше, чем у полного сканирования таблицы. Так как по нашим предположениям Fb < Fa, вложенные циклы будут минимизировать количество затронутых строк и уменьшать количество операций физического и логического ввода-вывода для таблицы А в сравнении с планом выполнения, который начинает выполняться непосредственно с индекса для фильтрации таблицы А. И соединение хэшированием, и соединение методом сортировки слиянием с таблицей А потребуют более дорогого полного сканирования таблицы или сканирования диапазона индекса по менее селективному фильтру. Так как блоки индекса для соединения
Выбор ведущей таблицы

255

кэшируются лучше, чем большая таблица А, то их считывание по сравнению с блоками таблицы будет достаточно недорогим. Таким образом, если лучший коэффициент фильтрации — это Fb1 то вложенные циклы минимизируют стоимость считывания данных из таблицы А.
Предыдущая << 1 .. 119 120 121 122 123 124 < 125 > 126 127 128 129 130 131 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100