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

 

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

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

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


Что не входит в диаграммы запросов

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

Списки выбора

Диаграммы запросов полностью исключают любые упоминания списков столбцов и выражений, которые выбирает запрос (то есть все, что находится между SELECT и FROM). Производительность запроса практически полностью определяется тем, какие строки выбираются из базы данных, и каким образом вы их получаете. Что вы делаете с этими строками, какие столбцы возвращаются, и какие выражения вы подсчитываете — это практически несущественно для производительности. Главное, но редкое исключение из этого правила — когда вы изредка выбираете так мало столбцов из таблицы, что база данных может выполнить запрос, используя только данные из индекса, совершенно не обращаясь к основной таблице. Иногда доступ только к индексу может существенно сэкономить ресурсы, HO он мало влияет на решения, которые вы принимаете относительно оставшейся части плана исполнения. Решать, нужно ли попробовать только индексный доступ, следует в последний момент процесса настройки и только если наилучший план без применения этой стратегии оказывается слишком медленным.
136

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

Сортировка и соединение

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

Имена таблиц

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

Подробные условия соединения

Детали условий соединения теряются, когда вы представляете соединения как простые стрелки с парой чисел, полученных откуда-то за пределами SQL. Если вы знаете статистику соединения, то подробности (например, столбцы соединения и как они между собой связаны) не играют роли.

Абсолютные размеры таблиц (в противоположность относительным)

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

137

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

Исходя из собственного опыта, я могу сказать: предположение о том, что одним из основных преимуществ стоимостных оптимизаторов является их способность выдавать для различных статистик по таблицам и индексам различные планы исполнения для одного и того же SQL-кода, является мифом. Эта теоретическая возможность часто используется в качестве аргумента против ручной настройки SQL приложения, так как результат может (теоретически) навредить такому же количеству покупателей, какому он может помочь, что сводит на нет все преимущества оптимизации. С другой стороны, мне пока еще предстоит найти запрос, для которого не существует плана исполнения, прекрасно работающего на любых распределениях данных. (Эти планы не являются оптимальными для всех распределений, но они достаточно близки к оптимальным, чтобы различия не имели значения.) В результате выясняется, что осторожная ручная настройка SQL продукта не обязательно должна повредить одному покупателю, чтобы помочь другому.
Предыдущая << 1 .. 63 64 65 66 67 68 < 69 > 70 71 72 73 74 75 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100