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

 

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

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

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


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

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

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

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

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

271

¦ Самая важная таблица для времени выполнения — это обычно корневая детальная таблица, и ее значительность приблизительно пропорциональна детальному коэффициенту соединения с этой таблицей от ведущей таблицы.

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

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

Отсутствующие индексы

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

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

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

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

¦ Как много конечных пользователей будут страдать от задержки в работе приложения, если SQL будет выполняться долго?

¦ Как часто конечные пользователи встречаются с задержками в работе приложения за неделю?

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

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

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

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