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

 

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

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

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


¦ Использование групп условий, объединенных при помощи OR или в списке IN, может привести к выполнению последовательности операций сканирования диапазонов, но только если каждое из этих условий указывает на допустимый диапазон. Например, IDColumn IN (123.124.125) преобразуется в три допустимых условия равенства, для которых выполняется сканирование трех диапазонов. Условие (Name= ’ Smi th' OR Name=' Jones ’) приводит к сканированию двух диапазонов, однако (Name= ’ Smi th' OR Name' IS NULL) не разрешает использовать индекс (кроме DB2), так как IS NULL не указывает на допустимый диапазон.

Если у вас есть условия, не определяющие ограниченный диапазон, по крайней

мере, по первому столбцу индекса, то единственный способ использовать индекс —

выполнить полное сканирование индекса, то есть сканирование всех записей индекса во всех листовых блоках. Базы данных чаще всего не выбирают полное ска-
56

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

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

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

Селективность для строк таблицы, полученных при помощи индекса

Так как индексы — это компактные и обычно хорошо кэшированные объекты по сравнению с таблицами, селективность сканирования диапазона индекса значит меньше, чем эффективный доступ к таблице. Даже когда индекс и таблица идеально кэшированы, селективность для таблицы важнее, чем для индекса, так как вы считываете около 300 строк индекса в листовом блоке одной операцией логического ввода-вывода, но должны выполнять отдельную операцию логического вво-да-вывода для каждой строки таблицы. Так мы приходим ко второй части оценки полезности индекса: насколько сильно индекс может сузить доступ к таблице? К счастью, производители баз данных достаточно умны, чтобы проверить все условия как можно раньше в плане выполнения, еще до обращения к таблице, где это позволяет сделать индекс. Это сокращает количество считываний данных из таблицы, когда индекс содержит столбцы, необходимые для оценки условия, — даже если база данных не может при помощи этого условия определить конечные точки диапазона сканирования. Например, рассмотрим таблицу Persons с одним индексом, включающим столбцы Area_Code. Phone_Number. Last_Name и Fi rst_Name. Возьмем запрос к этой таблице с условиями:

WERE Area_Code=916 AND UPPER(First_Name)=’IVA'

Только первое условие позволяет определить конечные точки диапазона сканирования индекса. Второе условие, по четвертому индексированному столбцу, не может сузить диапазон по трем причинам.

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

¦ Для третьего столбца индекса, Last Name, также не указаны условия равенства.

¦ Условие для First Name не в состоянии ограничить диапазон из-за функции UPPER.

К счастью, ни одна из этих причин не запрещает базе данных проверить второе условие до обращения к таблице. Так как в индексе есть столбец First Name, база
Вычисление селективности

57

данных может проверить условия для этого столбца при помощи данных из индекса. В этом случае база данных использует условие Area_Code для определения диапазона сканирования индекса. Затем она просматривает все записи индекса в диапазоне и отметает записи, в которых имена не равны Iva. Вероятный результат по этой селективной комбинации условий — одно или два считывания из таблицы.

Давайте изучим эту ситуацию подробнее и решим, стоит ли создавать для этой комбинации условий лучший индекс. Как для Area_Code, так и для First_Name мы увидим несимметричное распределение. Чаще всего будут запрашиваться наиболее распространенные коды областей и имена, поэтому используем стандартный подход к несимметричным распределениям и найдем отдельные значения селективности:

SELECT SUM(COUNT(Area_Code)*C0UNT(Area_Code))/

(SUM(COUNT(Area_Code))*SUM(C0UNT(*)))

FROM Customers GROUP BY Area_Code:

SELECT SUM(COUNT(Fі rst_Name)*C0UNT(FIrst_Name))/

(SUM(COUNT(FIrst_Name))*SUM(COUNT(*)))

FROM Customers GROUP BY First_Name:
Предыдущая << 1 .. 22 23 24 25 26 27 < 28 > 29 30 31 32 33 34 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100