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

 

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

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

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


Предположим, что при первом вычислении мы получим селективность, равную 0,0086, а при втором — 0,018. Далее предположим, что в нашей таблице 1 000 000 строк, а индекс указывает на 200 строк в каждом листовом блоке (меньше, чем обычно, так как у нас необычно широкий ключ индекса). Условие на Area_Code определяет количество сканируемых блоков индекса, поэтому сначала найдем количество строк, на которые указывает условие. Наша формула выглядит как 0,0086 х 1 000 000 = 8 600, то есть база данных сканирует 43 (8 600/20) листовых блока. В запросах к одной таблице всегда можно пренебречь считыванием корневого блока и средних блоков. Вероятнее всего, эти 43 листовых блока хорошо кэшированы и для их считывания требуется около миллисекунды.

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

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

8 600 операций считывания из таблицы могут стать проблемой, но, к счастью, у нас есть дополнительная селективность условия по столбцу Fi rst Name, которая сокращает количество строк приблизительно до 155 (8 600 х 0,018). Для таблицы будет выполнено приблизительно 155 операций логического ввода-вывода и несколько операций физического ввода-вывода, так как коэффициент успешного попадания в кэш для таблицы хуже, чем для более компактного индекса.

Селективность фильтра для нескольких столбцов, 0,0086 х 0,018 = 0,000155, позволяет попасть в диапазон, подходящий для индексного доступа, хотя селективность только по первому столбцу находится в переходной зоне. Обратите вни-
58

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

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

Комбинирование индексов

Случается, что база данных находит фильтры с условиями равенства, которые указывают на различные одностолбцовые индексы. Объединив операции сканирования диапазонов этих индексов, база данных может получить селективность многостолбцового фильтра еще до того, как начнет обращение к таблице. Давайте еще раз воспользуемся предыдущим примером запроса, который указывает код области и имя покупателя, но заменим многостолбцовый индекс одностолбцовыми индексами по двум нужным нам столбцам. Далее заменим условие UPPER(Fi rst_Name) на простое соответствие по столбцу, предполагая, что все значения хранятся в верхнем регистре. Типичные условия выглядят следующим образом:

WHERE Area_Code=415 AND FirstJame=1BRUCE1:

Теперь можно предположить, что в листовом блоке находится обычное количество строк — 300 или более, так как одностолбцовые индексы созданы по коротким столбцам. Используя те же значения селективности фильтров по одному столбцу и предполагая, что в таблице содержится 1 ООО ООО строк, можно предсказать, что условие для Area_Code даст 8 600 (0,0086 х 1 000 000) строк, для чего потребуется использовать 29 (8 600/300) листовых блоков индекса. Второе сканирование диапазона индекса, для удовлетворения условия для First Name, даст 18 000 (0,018 х 1 000 000) строк, что требует использования 60 (18 000/300) листовых блоков индекса. Так как оба условия являются условиями равенства, база данных находит два уже отсортированных списка идентификаторов строк и может легко объединить их, отыскав те же 155 идентификаторов строк таблицы, как и в случае с многостолбцовым индексом.

Описанная здесь операция, слияние списков идентификаторов строк, полученных из двух индексов, называется операцией AND-EQlIAL MERGEjim индекса (слияние по условиям равенства и условию И), и база данных может выполнять эту операцию с любым количеством условий равенства для одностолбцовых индексов. Стоимость доступа к таблице такая же, как при поиске строк по многостолбцовому индексу, но считать необходимо больше листовых блоков индекса — в данном случае 89 (29 + 60) вместо 43 в предыдущем примере.
Предыдущая << 1 .. 23 24 25 26 27 28 < 29 > 30 31 32 33 34 35 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100