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

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Артемов Д.В. -> "Microsoft SQL Server 2000" -> 65

Microsoft SQL Server 2000 - Артемов Д.В.

Артемов Д.В. Microsoft SQL Server 2000 — М.: Издательско-торговый дом «Русская Редакция», 2001. — 576 c.
ISBN 5-7502-0154-6
Скачать (прямая ссылка): artemov.pdf
Предыдущая << 1 .. 59 60 61 62 63 64 < 65 > 66 67 68 69 70 71 .. 187 >> Следующая


174

Microsoft SQ L Se rver 2000, Новейшие технологии

вает на кластерный индекс дополнительные требования по стабильности. Как это понять? При работе с версией 6.x определение схемы индексов напоминало балансирование на проволоке. С одной стороны, они нужны для выполнения операций выборки, с другой — при модификации данных все индексы должны быть адаптированы к внесенным изменениям, что создавало немалые накладные расходы. В итоге разработчик был вынужден искать компромисс между обеспечением высокую скорость исполнения операций SELECT (индексы в основном помогают) и необходимостью не замедлять исполнение операций UPDATE (тут индекс помогает при поиске записей, соответствующих критерию обновления, мешает, замедляя выполнение самой операции) или INSERT. Версия 8.0 снимает остроту проблемы, но только если модификации не затрагивают ключ кластерного индекса. В этом случае некластерный индекс будет затронут в минимальной степени, так как его основной указатель, связывающий его ключ с ключом кластерного индекса, остается неизменным.

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

CREATE TABLE test (fldl CHAR(10), fld2 CHAR(IO)) CREATE INDEX indl ON test (UdD CREATE INDEX ind2 ON test (fld2)

Теперь заполним таблицу данными и выполним запрос:

SET SHOWPLAN TEXT ON

SELECT * FROM" test WHERE fldl like ¦ 1' OR fld2 LIKE '56'

Оптимизатор создает такой план исполнения:

!-Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([Lempdb]. [dbo], [test])) | -Hash Match(Union)

-Filter(WHERE:(like([test].[fldl], '1' ))) -Index Seek(OBJECT:([tempdb],[dbo].[test], [indl]), SEEK:([test].[fld1] BETWEEN '1' AND ' 1') ORDERED) I-Filter(WHERE:(like([test].[fld2], '56'))) I-Index Seok(0BJECT:([tempdb].[dbo].[test]. [ind2]), SEEK:([test].[fld2] BETWEEN '56' AND '56') ORDERED)

Как видите, оптимизатор использует оба индекса для поиска набора индексных ключей, удовлетворяющих указанному критерию, а затем строит их пересечение, чтобы определить на-

www.books-shop.com

ГЛАВА 3; Управление базами данных

бор записей. «Ну и что?» — спросите Вы. А то, что теперь можно и должно создавать столько индексов, сколько нужно. Только вот каких? В силу того, что индексов может быть много, оптимизатор способен использовать несколько за раз, и наличие индексов почти не влияет на скорость обновления таблиц, у администратора или разработчика может появиться искушение создать индексы на все возможные комбинации полей. Вряд ли это будет правильно: возможности по построению пересечения индексов скорее подталкивают к созданию более узких и простых, нежели сложных составных индексов. Если индекс построен по комбинации полей а зап-

рос сформулирован как:

SELECT Fld3, Fld2 FROM MyTaЫе WHERE Fld2 = '1234'

индекс поможет мало, поскольку критерий поиска использует поле из середины составного ключа. Это может выглядеть так:

CREATE TABLE test (fldl CHAR(10), fld2 CHARdO)) CREATE INDEX indl ON test (fldl, fld2)

SELECT * FROM test WHERE fld2 = '56' SELECT * FROM test WHERE fldl = '56'

на план исполнения. Первый запрос:

Index Scan(OBJECT:([ternpdb],[dbo], [test],[indl]), WHERE: ([test], [ fld2]=[@>1 ]))

Второй запрос:

Index Seek(OBJECT:([tempdb],[dbo].[lest].[indl]), SEEK: ([test],[fld1] = [@1]) ORDERED)

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

Данная версия книги выпущена электронным издательством "Books-shop". Распространение, продажа, перезапись данной книги или ее частей ЗАПРЕЩЕНЫ. О всех нарушениях просьба сообщать по адресу piracy@books-shop.com

•jyg Microsoft SQL fewer 2000, Новейшие технологии

www.books-shop.com

Отмечу также, что SQL Server 2000 позволяет создавать индексы по таким полям, которые ранее были недоступны для индексирования. Я имею в виду поля типа Bit и вычисляемые поля. Полезность индекса по полю, которое может иметь только два значения, мне представляется довольно сомнительной, кроме случаев, когда одно из значений занимает лишь небольшую часть записей. А вот вычисляемые поля — дело другое. Индекс снимает необходимость каждый раз производить вычисления и должен заметно ускорять выполнение запроса. Только имейте в виду: выражение должно быть детерминированным, т. е. при одном и том же наборе входных параметров оно должно всегда возвращать одинаковый результат. Для этого из выражения надо исключить все недетерминированные функции, поля типа Float, а при создании таблицы параметр ANSINULL должен быть активен (значение ON). Сама команда создания индексов по вычисляемым полям должна выполняться в определенном окружении. Это окружение создается набором команд SET, описанных в следующем разделе. Важно также помнить, что все команды модификации данных тоже должны выполняться в рамках соединения, настроенного должным образом.
Предыдущая << 1 .. 59 60 61 62 63 64 < 65 > 66 67 68 69 70 71 .. 187 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100