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

 

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

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

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 65 66 67 68 69 70 < 71 > 72 73 74 75 76 77 .. 161 >> Следующая


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

Перед тем как я продемонстрирую сложный процесс оптимизации порядка соединения для многостороннего соединения с использованием диаграммы запроса, давайте просто посмотрим, что диаграмма на рис. 5.1 говорит нам о сравнительной стоимости обоих порядков для двустороннего соединения, возможных в предложенном SQL-запросе. С удивительно высокой точностью стоимость только индек-
Полные диаграммы запросов

139

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

1. Используя индекс на фильтре для Е, база данных должна начать с получения

0,1 х С строк из ведущей таблицы Е.

2. Следуя вложенным циклам по направлению к главной таблице D, главный коэффициент соединения показывает, что база данных получит 0,1 х С х 0,98 строк из D.

3. Складывая результаты шагов 1 и 2, получим общее количество строк из обеих таблиц: (0,1 х С) + (ОД х С х 0,98).

4. Вынесем за скобки С и 0,1 из обоих выражений. Общее количество строк, полученных базой данных, равно С х (0,1 х (I + 0,98)) или 0,198 х С.

Начиная с противоположного конца соединения, также выразим стоимость через С, но зададим через С размер D. Зная размер D, выраженный через С, стоимость запроса в терминах С вычислим следующим образом.

1. Для каждой строки из D база данных находит приблизительно 20 строк в Е, что показывает детальный коэффициент соединения. Однако только 98 % строк в E в принципе подходят к строкам из D, поэтому общее количество строк С должно быть в 20/0,98 больше, чем количество строк, полученных из D. Следовательно, количество строк, полученных из D, равно С х 0,98/20.

2. Используя индекс для получения только отфильтрованных строк из D, мы получим половину строк из ведущей таблицы, или С X 0,5 X 0,98/20.

3. При выполнении соединения с E база данных получает в 20 раз больше строк из этой таблицы, то есть 20 х С х 0,5 х 0,98/20 или С х 0,5 х 0,98.

4. Складывая количества строк из двух таблиц и вынося за скобки общие множители, получим общую стоимость: С х (0,5 х 0,98 х ((1 / 20) +1)) или 0,5145 х С. В действительности абсолютная стоимость нас не интересует. Нам важна относительная, поэтому наилучший план можно выбрать исходя из того, что, каково бы ни было С, 0,198 х С всегда будет меньше 0,5145 х С. В диаграмме запроса есть вся информация, которую вам необходимо знать: что план, начинающийся с E и присоединяющий D, будет намного быстрее (приблизительно в 2,6 раз), чем план, начинающийся с D и присоединяющий Е. Если вы найдете другие, близкие значения, то стоит подумать о том, что оценка стоимости на основе количества строк была не очень верна, но об этом я расскажу позже. Самое главное, что следует запомнить, так это то, что диаграмма запроса отвечает на основные вопросы, относящиеся к оптимизации запроса. Вам просто необходим эффективный способ использования диаграмм запросов для понимания и настройки сложных запросов.

Создание диаграмм запросов

Теперь, когда вы знаете, что означает диаграмма запроса, нужно познакомиться с методом создания диаграммы на основе оператора SQL, включая шаги, которые не требовались для показанного выше запроса, но которые вам понадобятся позже.
140

5. Диаграммное изображение простых запросов SQL

1. Начните с произвольно выбранного псевдонима таблицы из раздела FROM и поместите его в середину пустой страницы. Эту таблицу я буду называть центральной таблицей, подразумевая, что она будет текущей точкой, начиная с которой мы будет добавлять дальнейшие элементы в диаграмму запроса. Для нашего примера в качестве начальной точки я выберу псевдоним Е, просто потому что он первым встречается в запросе.

2. Найдите условия соединения, соответствующие единственному значению первичного ключа центральной таблицы. Для каждого такого соединения нарисуйте стрелку, указывающую вниз, на центральную таблицу, пометив начало стрелки псевдонимом на противоположной стороне соединения. (Обычно вы найдете максимум одно соединение с таблицей сверху, по причинам, которые я объясню позже.) Если связь представляет внешнее соединение, добавьте посередине связи острие стрелки, направленное на дополнительную таблицу.

В нашем примере соединения с первичным ключом таблицы Empl oyees, предположительно Employee_ID, нет. Если вы хотите убедиться, что Department_ID — это достаточно хорошее имя для первичного ключа Empl oyees, то можете проверить объявленные ключи и уникальные индексы таблицы. Если вы подозреваете, что соединение на самом деле может быть уникальным, но разработчик базы данных не объявил и не включил уникальность при помощи объявленного ключа или индекса, то можете проверить уникальность при помощи SELECT C0UNT(*). COUNT(DISTINCT DepartmentalD) FROM Empl oyees:. Однако вы, наверное, будете удивлены, насколько редко возникают какие-либо сомнения насчет того, с какой стороны соединение является уникальным, так как очень часто помогают названия столбцов и таблиц. Так что обычно вы можете работать, используя собственные догадки, и проверяя их, только если полученный результат будет работать хуже, чем вы ожидали или хуже, чем требуется.
Предыдущая << 1 .. 65 66 67 68 69 70 < 71 > 72 73 74 75 76 77 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100