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

 

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

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

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 18 19 20 21 22 23 < 24 > 25 26 27 28 29 30 .. 161 >> Следующая

Пути доступа для одной таблицы

49

С другой стороны, если выполняется доступ к диапазону значений, например, Reti rement_Date BETWEEN '2002/01/01' and '2003/01/01', то вы обнаружите целую последовательность отсортированных списков идентификаторов строк для каждой даты из диапазона. Движение считывающей головки диска будет менее упорядоченным и, следовательно, менее эффективным. Самокэширование в этом случае может вовсе не произойти, если время выполнения запроса превышает срок жизни блоков в кэше. Даже если вы введете условие равенства, то, возможно, получите именно этот менее эффективный вариант в случае, когда индекс состоит из нескольких столбцов. Например, LastJIame-' Smi th' — это в действительности условие на диапазон для индекса (Last_Name. F і rst Name), так как существует множество пар с различными значениями, удовлетворяющих этому условию для одного столбца.

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

¦ Если таблица достаточно большая, и разница между полным сканированием таблицы и индексным доступом к ней будет весьма существенна, лучше выбрать более жесткое условие и использовать индекс. В противном случае может быть возвращено строк больше, чем требуется. Позже я подробно опишу, почему несколько хорошо спроектированных запросов обязательно возвращают существенную часть (до 1 %) большой таблицы. Реальные приложения существуют в основном для того, чтобы предоставить конечным пользователям удобный доступ к данным. Когда пользователи работают с данными в оперативном режиме, им становится неудобно обрабатывать большие объемы данных. Они терпимо относятся к большим объемам данных в отчетах, но и отчет, предоставляющий больше информации, чем пользователь может усвоить, является плохо проработанным. В Главе 10 мы подробно обсудим способы улучшения запросов, возвращающих слишком много строк.

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

2. Основы доступа к данным

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

Вычисление селективности

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

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

¦ Определение условия для индексного диапазона.

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

¦ Указание строк таблицы, полученных из индекса.

Иногда условия не определяют границы индексного диапазона, но, тем не менее, их можно оценить в индексе до осуществления доступа к таблице. Эти условия требуют обращения к строкам, которые в конечном итоге исключаются из результирующего набора, но происходит это в индексе, а не в таблице.
Предыдущая << 1 .. 18 19 20 21 22 23 < 24 > 25 26 27 28 29 30 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100