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

 

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

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

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 128 129 130 131 132 133 < 134 > 135 136 137 138 139 140 .. 161 >> Следующая


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

Также рассмотрите и основные внешние эффекты. Например, оперативные задержки для приложения поддержки покупателей, работающего в реальном времени, могут привести к тому, что покупатели займутся поисками другого поставщика приложений, а ущерб от этой проблемы просто неоценим! Пакетные задержки, приводящие к взысканиям за пропущенные конечные сроки, тоже могут принести огромные расходы. Если задержки работы SQL-запроса слишком дороги, а улучшения за счет добавления нового индекса существенны, не сомневайтесь, что индекс лучше добавить. В противном случае, взвесьте все за и против.

ВНИМАНИЕ -----------------------------------------------------------------------

Гораздо проще добавить индексы, чем избавиться от них! Если индекс используется в реальной работе какое-то время, то риск падения производительности от его удаления сильно возрастает. Кроме того, невозможно заранее гарантировать, что удаление индекса будет безопасно. После того, как индекс введен в работу, первоначальное его обоснование быстро забывается, а новый код может стать зависимым от индекса, даже если никто об этом догадываться не будет. Время сказать «нет» плохому индексу наступает еше до того, как он становится реальной частью промышленного окружения, от которого зависит конечный пользователь.
Неразрешимые проблемы

273

Соединения, не прошедшие фильтрацию

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

Как же оптимизировать такой запрос, если невозможно руководствоваться селективностью фильтров? Для планов с вложенными циклами едва ли играет роль выбранный порядок соединения, если, конечно, вы придерживаетесь дерева соединения. Однако для этих запросов лучше всего подходят соединения хэшированием, или, если их нельзя применить, то соединения методом сортировки слиянием. Предполагая, что можно выполнять соединения хэшированием, база данных должна считать все три таблицы методом полного сканирования и хэшировать меньшие таблицы, Al и А2, по возможности кэшируя результат в памяти. Затем при последнем проходе через самую большую таблицу, М, каждая хэшированная строка быстро сопоставляется с подходящими хэшированными в памяти строками таблиц Al и А2. Стоимость запроса в идеальном случае приблизительно равна стоимости трех полных сканирований таблиц. База данных просто не может отработать лучше, даже теоретически, если предполагать, что требуются все строки из всех трех таблиц. Чаще всего стоимостные оптимизаторы хорошо справляются с задачей поиска оптимальных планов для таких запросов без ручной помощи.

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

M

Al

А2

Рис. 9.5. Неотфильтрованное трехстороннее соединение

Неразрешимые проблемы

Пока что я описывал стратегии решения задач, которые я называю строгими задачами настройки SQL Это задачи, в которых текст медленного запроса определяет
274

9. Особые случаи

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

Улучшить данный оператор SQL, чтобы вернуть в точности тот же набор строк, который он возвращает сейчас (то есть без изменения оставшейся части приложения) быстрее, чем за некоторое предопределенное целевое время выполнения.

Предполагая, что предопределенное целевое время выполнения задано рационально, согласно реальным требованиям бизнеса, можно перечислить четыре причины, по которым данная задача может быть неразрешима.
Предыдущая << 1 .. 128 129 130 131 132 133 < 134 > 135 136 137 138 139 140 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100