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

 

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

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

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

38

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

полагается, что запрошенный диапазон содержит хотя бы несколько строк), и идентификатор строки для первой строки диапазона.

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

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

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

Если в блоке индекса содержится приблизительно 300 записей, то на первом некорневом уровне будет примерно 300 блоков. Это достаточно малое значение для успешного кэширования, поэтому вы можете предполагать, что считывание этих блоков индексов будет исключительно логическим, без выполнения операций физического ввода-вывода. На нижнем, листовом уровне индекса, если индекс состоит из трех и более уровней, может быть гораздо больше трехсот листовых блоков. Ho если в базе данных используется действительно объемный индекс, то на листовом уровне индекса находится порядка п/300 блоков, где п — количество индексированных строк, а база данных может эффективно кэшировать 1 000 или более блоков индекса.

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

39

Стоимость индекса

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

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

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