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

 

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

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

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


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

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

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

199

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

Первый пример в разделе «Порядок 8-стороннего соединения» с диаграммой на рис. 6.2 хорошо иллюстрирует минимальное улучшение производительности, полученное благодаря соединениям хешированием. Обратите внимание, что детальные коэффициенты соединения над узлами ОТ и ODT — это значения, равные нескольким миллионам, что указывает, что это соединения с крошечным набором строк таблицы Code_Transl ati ons. Так как каждый набор допустимых строк для данных значений Code_Type достаточно мал, вам потребуется меньше операций логического ввода-вывода для того, чтобы за один раз считать весь набор строк через индекс по столбцу Code_Type. Поэтому выполните соединение хешированием вместо того, чтобы обращаться к каждой строке (вероятно, несколько раз) через вложенные циклы каждый раз, когда она потребуется. Оба варианта дешевы и займут лишь небольшую часть времени выполнения, так как количество возвращаемых запросом строк невелико, а физический индекс и блоки таблицы Code_Translations будут полностью кэшированы.

Следующее упражнение содержит в себе все рассмотренные проблемы. В нем больше фильтров и исключений, чем вы, вероятно, увидите за всю свою жизнь. Диаграмма запроса на рис. 6.33 намного сложней и запутанней, чем я когда-либо встречал в реальных задачах настройки.

Упражнение

M 0.5

Al 0.4 А20.3

BI 0.5 В2 0.08

ВЗ

1

Cl 0.1

С2 С302 С4 С5 10

Ў

D30.4

D10.7 D20.7

Рис 6.33. Нереально сложная задача

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

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

попрактиковавшись на других проблемах. Найдите наилучший порядок соединения. Найдите лучший метод соединения для всех связей, предполагая, что в таблице Al 30 ООО ООО строк и полагая, что полное сканирование таблицы предпочтительней для любой таблицы, из которой будет считано минимум 5 % строк. Найдите набор необходимых индексов по первичным ключам, набор необходимых индексов по внешним ключам и все остальные индексы, которые могут потребоваться. Найдите все изменения в SQL-коде, которые могут понадобиться для того, чтобы суметь использовать скрытые фильтры как можно раньше. Сделайте обычные предположения о ссылочной целостности.
Диаграммное изображение и настройка сложных SQL-запросов

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

¦ Запрос отображается на одно дерево.

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

¦ Для всех соединений есть указывающие вниз стрелки (соединения уникальны на одном конце).

¦ Внешние соединения не фильтруются, указывают вниз; под внешними соединениями могут быть только внешние соединения.

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

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

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

Запросы не всегда соответствуют этой стандартной простой форме. В таких случаях я называю запросы сложными. Как я продемонстрирую в этой главе, некоторые сложные запросы являются следствием ошибок в дизайне базы данных или приложения. Также причиной появления сложных запросов могут быть ошибки реализации. Зачастую ошибки такого типа действительно приводят к появлению неправильных запросов. В этой главе вы узнаете об аномалиях, с которыми можете встретиться в диаграммах запросов и которые явно извещают
Предыдущая << 1 .. 93 94 95 96 97 98 < 99 > 100 101 102 103 104 105 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100