Index название_индекса

on [[база_данных.]владелец.]название_таблицы (название_столбца

   [,название_столбца]...)

[with {{fillfactor | max_rows_per_page}= x,

    ignore_dup_key, sorted_data,

   [ignore_dup_row | allow_dup_row]}]

[on название_сегмента]

Индексирование по нескольким столбцам: составные индексы

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

Составной индекс следует использовать в том случае, когда нужно вести поиск по комбинации значений в нескольких столбцах. В этом случае комбинацию значений данных можно рассматривать как одно составное значение. Например, предположим, что в таблицеfriends_etc нужно связать составной индекс со столбцами pname и sname. В этом случае в скобках нужно указать названия всех столбцов, включаемых в составной индекс, как в следующем операторе:

 create index nmind

on friends_etc (pname, sname)

 Порядок следования названий столбцов в этом списке влияет на порядок следования (сортировку) составных значений и этот порядок может отличаться от порядка следования этих столбцов в операторе создания таблицы create table. Например, в предыдущем операторе столбцы pname и sname можно указать в другом порядке.

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

В составной индекс как уже указывалось можно включать названия двух и более столбцов. Эти столбцы вместе со столбцом sensitivityобразуют составной индекс. Составной индекс следует использовать в том случае, когда комбинацию значений данных можно рассматривать как одно составное значение, по которому удобно вести поиск. Например, в таблице friends_etc был определен составной индекс, связанный со значениями в столбцах pname, sname и sensitivity (этот столбец добавляется SQL Сервером автоматически). Как уже было указано, оператор определения индекса в этой таблице имеет следующий вид:

 create index nmind

on friends_etc (pname, sname)

 Порядок следования названий столбцов в этом списке может отличаться от  порядка следования этих столбцов в операторе создания таблицы create table. Например, в предыдущем операторе столбцы pname и sname можно указать в другом порядке. SQL Сервер всегда автоматически добавляет столбец sensitivity в качестве последнего в каждый составной индекс.

Использование опции unique

 Уникальный (unique) индекс, связанный с некоторым столбцом, препятствует появлению в этом столбце двух одинаковых значений, включая неопределенное значение NULL. В этом случае система сама проверяет отсутствие дублирующихся значений, во время определения такого индекса, если в таблице уже есть некоторые данные, и такая проверка повторяется после каждого оператора модификации данных insert или update.

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

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

Использование счетчиков в неуникальных индексах

 Опция identity in nonunique index (счетчик в неуникальном индексе) автоматически включает столбец счетчика во все индексы таблицы, тем самым делая их все уникальными. Эта опция базы данных делает логически неуникальные ключи фактически уникальными, что позволяет использовать их в обновляющих курсорах (uptable cursors) и при считываниях на нулевом уровне изоляции (isolation level 0 reads).

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

Опцию identity in nonunique index следует использовать в том случае, если пользователь планирует работать с курсорами или выполнять считывание на нулевом уровне в таблице с неуникальными индексами. Уникальный индекс обеспечивает установку курсора на нужной строке, перед тем как выполняется следующая операция fetch (загрузка) с помощью этого курсора.

Использование опций fillfactor и max_rows_per_page

 Достаточно редко у пользователя возникает необходимость заняться тонкой настройкой производительности системы, и в этом случае он может использовать опции fillfactor (фактор плотности) и max_rows_per_page (максимальное число строк на страницу). Эти опции имеет смысл использовать только при создании индексов для таблиц, уже содержащих некоторые данные.

FILLFACTOR

 С помощью опции fillfactor пользователь задает степень заполненности индексной страницы, которую должен поддерживать SQL Сервер. Здесь принимается во внимание количество свободной памяти, которое можно оставить на индексной странице, поскольку при полном заполнении страницы системе требуется дополнительное время, чтобы освободить место для поступившей информации.

По умолчанию этот фактор равен 0 и это же значение используется, если пользователь не указал опции заполнения. Системный администратор может изменить значение этого фактора, принимаемое по умолчанию, с помощью системной процедуры sp_configure(конфигурация).

Далее приведен пример оператора создания индекса с использованием опции fillfactor:

 create index postalcode_ind

on friends_etc(postalcode)

with fillfactor = 100

 Если значение фактора плотности равно 100, то полностью заполняется каждая страница. Такой фактор целесообразно задавать в том случае, если пользователь точно знает, что никакое индексированное значение в таблице не будет изменяться.

MAX_ROWS_PER_PAGE

 Опция max_rows_per_page ограничивает число строк, которые SQL Сервер может разместить на одной странице памяти. Малое значение этого параметра ограничивает блокировку и имеет смысл только для часто используемых таблиц. Малые значения этого параметра приводят к дополнительному расходу памяти для индекса.

По умолчанию значение этой опции равно 0 это же значение используется, если пользователь не указал никакого максимума. Пользователь может изменить это значение, принимаемое по умолчанию, с помощью сиcтемной процедуры sp_relimit.

Правильное значения этого параметра, задаваемое пользователем, заключено в интервале от 1 до 256.

Следующий оператор создания индекса использует опцию max_rows_per_page:

 create index postalcode_ind

on friends_etc(postalcode)

with max_rows_per_page = 10

Использование кластеризованных и некластеризованных индексов

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

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

Логически главный ключ выбирается на этапе проектирования базы данных. Однако пользователь может явно определить главные ключи, внешние ключи и общие ключи (пары ключей часто используемые при соединениях) с помощью системных процедур sp_primarykey,sp_foreignkey и sp_commonkey. Информацию о ключах можно получить с помощью системных процедур sp_helpkey, а информацию о столбцах, по которым целесообразно осуществлять  соединение с помощью системной процедуры sp_helpjoins.

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

Об определении главных и внешних ключей можно посмотреть в главе 15 “Триггеры: обеспечение целостности данных”. Полная информация о системных процедурах дается в Справочном руководстве SQL Сервера.