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

 

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

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

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

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

45

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

Индексный доступ к таблицам

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

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

Идентификатор

строки

Рис. 2.5. Индексный доступ к таблице

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

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

Давайте сравним методы индексного доступа и полного сканирования таблицы на определенном примере. На рис. 2.6 показаны два пути, ведущие к пяти строкам, обозначенным черным цветом, в таблице, состоящей из 40 блоков. Обычно в таких таблицах содержится приблизительно 3 200 строк.

Идентификатор

строки

Считывание нескольких блоков по 64 Кбайт

Рис. 2.6. Индексный доступ и полное сканирование таблицы

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

В случае полного сканирования таблицы, если до его начала блоки таблицы еще не находятся в кэше, база данных выполняет пять считываний фрагментов данных размером по 64 Кбайт, то есть считывает всю таблицу до отметки заполнения. Затем сервер баз данных проходит через все 40 блоков и 3 200 строк, отметая все, кроме пяти строк, удовлетворяющих условию запроса. Если у базы данных нет кэша и вы заботитесь только о времени, которое занимает перемещение считывающих головок диска при выполнении физического ввода-вывода, то вы насчитаете семь операций физического ввода-вывода для случая индексированного доступа и пять операций для полного сканирования таблицы, и, следовательно, выберете полное сканирование. Однако небольшая таблица и небольшой индекс, как в этом случае, скорее всего, полностью кэшированы. Семь операций логического ввода-вывода дешевле, чем 40 операций логического ввода-вывода, даже если
Пути доступа для одной таблицы

47

они нужны для полного сканирования таблицы. Кроме затрат на логический ввод-вывод, индексированный план выполнения избегает затрат на работу процессора, которая выполняется при просмотре более чем 3 ООО ненужных строк.

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