Оператор drop index

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

DROP INDEX <table name>.<index name>

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

Принятие решения об используемом типе индекса

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

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

Избирательность

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

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

Если для получения доступа к данным вслед за выполнением одной операции поиска в некластеризованном индексе приходится выполнять еще несколько дополнительных операций поиска в кластеризованном индексе, то, по-видимому, лучше прибегнуть к полному просмотру таблицы. В противном случае по мере уменьшения избирательности ключа происходит невероятно быстрый, почти экспоненциальный рост количества выполняемых операций. Есть основания полагать, что при наличии всего лишь 90-95% уникальных значений в индексированном столбце нет смысла использовать некластеризованный индекс, поскольку в связи с циклической организацией процесса доступа к данным создаются весьма значительные издержки.

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

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

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

Учет затрат на сопровождение индексов

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

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

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

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

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

Выбор наиболее подходящего кластеризованного индекса

След\ет учитывать, что на таблице может быть задан только один кластеризованный индекс, поэтому выбирать его нужно очень тщательно.

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

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

CREATE TABLE MyTableKeyExample (

Columnl intIDENTITY

PRIMARY KEY NONCLUSTERED, Coluinn2 int

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

Следует учитывать, что после внесения изменений в столбец (столбцы), на котором определен кластеризованный индекс, в СУБД SQL Server может потребоваться выполнение полной пересортировки всей таблицы (напомним, что при использовании кластеризованного индекса порядок сортировки строк таблицы и расположения