Поиск по кластеризованному индексу 102

Поиск no кластеризованному индексу 209 *

Puc. 8.9. Организация поиска строк с данными

каждой такой операции поиска потребуется приблизительно 3-4 логических операций чтения, или 15-24 дополнительных операций чтения. На первый взгляд кажется, что такое увеличение количества операций не имеет особого значения, поэтому рассмотрим эту ситуацию под другим углом зрения.

Количество логических операций чтения увеличивается от минимального значения, 3, до максимального значения, 24, что соответствует увеличению объема работы, подлежащей выполнению, на 800%.

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

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

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

Создание, модификация и удаление индексов

Операции создания, модификации и удаления индексов осуществляются во многом так же, как и применительно к другим объектам, таким как таблицы. В данном разделе рассматривается каждая из этих операций, начиная с операции CREATE.

Для создания индексов применяются два указанных ниже способа.

Создание индекса с помощью явно заданной команды CREATE INDEX.

Неявное создание индекса как обязательного объекта в результате ввода в действие некоторого ограничения.

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

Оператор create index

Оператор CREATE INDEX осуществляет действие, полностью соответствующее его смыслу, - создает на )тсазанной таблице или представлении индекс, основанный на заданных столбцах.

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

CREATE [UNIQUE] [CLUSTEREDNONCLUSTERED] NDEX <index name> ON <table or view name>(<column name> [ASCJDESC] [,...n]) NCLUDE (<column name> [, -n]) WITH

PAD INDEX = { ON I OFF }]

] FILLFACTOR = <fillfactor>] ] IGNORE DUP KEY = { ON OFF }] ] DROP EXISTING = { ON OFF }] ] STATISTICS NORECOMPUTE = { ON OFF }] ] SORT IN TEMPDB = { ON OFF }] ] ONLINE = { ON I OFF } ] ALLOW ROW LOCKS = { ON OFF } ] ALLOW PAGE LOCKS = { ON OFF } ] MAXDOP = <maximum degree of parallelism>

[ON {<filegroup> <partition scheme name> DEFAULT }]

В последней версии SQL Server многие опции синтаксической конструкции оператора создания индекса изменились, поэтому варианты, применявшиеся в предыдущих верасях, теперь рассматриваются как устаревшие. Тем не менее во многих разработках встречаются случаи применения устаревшего синтаксиса в це/гях обеспечения совместимости

с предыдущими версиями SQL Server. Однако устаревшие варианты синтаксических конструкций больше не поддерживаются и со временем их применение будет запрещено, поэтому автор настоятельно рекомендует при любой возможности стремиться использовать более новый синтаксис.

Для создания индексов XML применяется аналогичный синтаксис, который, тем не менее, имеет существенные отличия. Информация по этой теме приведена в конце данного раздела.

Синтаксическая структура оператора создания индекса соответствует такому же общему образцу, CREATE <object type> <object name>, как и многие другие операторы создания объектов, рассматривавшиеся до сих пор (а также напоминает те операторы создания объектов, о которых еще будет идти речь в настоящей книге). Специфика оператора создания индекса состоит в том, что в нем используется несколько промежуточных параметров, которые не встречаются в других операторах.

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

Обязательной является только констр}тсция ON <table or view name> (<column name>), a все остальные конструкции, которые следуют за ней, являются необязательными. Элементы синтаксического определения оператора создания индекса могут применяться в самых разных сочетаниях. Многие из этих элементов используются редко, а другие (такие как FILLFACTOR) мог)пг оказывать существенное влияние на производительность системы и действия, ос\тцествляемые в системе, поэтому ниже приведено последовательное описание различных опций.

Опция ASC/DESC

ЬСлючевые слова AS С и DESC позволяют указывать, должен ли применяться в индексе порядок сортировки по возрастанию или по убыванию. По умолчанию применяется ключевое слово ASC (сокращение от ascending), которое, как и следовало ожидать, означает порядок сортировки по возрастанию.

На первый взгляд может показаться, что от выбора порядка сортировки по возрастанию или по убыванию мало что зависит, поскольку СУБД SQL Server позволяет просто выполнять просмотр в индексе в обратном порядке, если для поиска данных потребуется применение противоположного порядка сортировки. Тем не менее на практике выбор того или иного порядка сортировки влечет за собой более важные последствия. Просмотр индекса в обратном порадке осуществляется вполне успешно, если при этом приходится рассматривать только один столбец или если во всех используемых столбцах порадок сортировки остается всегда одинаковым, а если применяется индекс, в котором разные столбцы отсортированы по-разному, то ситуация изменяется. Иными словами, дела обстоят совсем иначе, если для поиска данных требуется, чтобы один столбец был отсортирован по возрастанию, а другой - по убыванию. Данные столбцов, включенных в состав индекса, хранятся вместе, поэтому переход к способу просмотра индекса для одного столбца в обратном порядке приводит