Кластерные индексы SQL Server

Question

У меня есть фон Oracle, и использование «индексированных организованных таблиц» (IOT) для каждой таблицы звучит необоснованно в Oracle, и я никогда не видел этого. В SQL Server каждая база данных, над которой я работал, имеет кластеризованный индекс для каждой таблицы, что совпадает с IOT (концептуально).

Почему? Есть ли какая-либо причина для использования кластерного индекса во всем мире? Мне кажется, что они были бы хороши только для нескольких дел.

Благодаря

Answer 1

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

Когда это хорошо, чтобы не иметь кластерный индекс

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

Кластеризованные индексы

Кластерные индексы организовать данные в таблице на основе столбцов в кластерном индексе. Если вы скопируете неправильную вещь, например, uniqueidentifier, это может замедлить работу (см. Ниже).

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

Если у вас слишком много ключей в вашем кластерном индексе, это также может замедлить работу.

Общие правила для кластерных индексов:

Не группировать по любым VARCHAR столбцов.

Кластеризация на колонках INT IDENTITY обычно лучше всего.

Кластер на то, что вы обычно ищете.

кластеризация на UniqueIdentifiers

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

Резюме

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

Answer 2

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

Answer 3

Я бы не знал, почему вы предпочитаете кучу по кластерному индексу большую часть времени. Используя кластеризацию, вы получаете один индекс по своему выбору бесплатно. В большинстве случаев это первичный ключ (который вы, вероятно, хотите использовать в любом случае!).

Кучи в основном предназначены для особых ситуаций.

Answer 4

Кластеризованный индекс - это не то же самое, что индексированная таблица. При использовании IOT каждое поле должно участвовать в ключе IOT. Кластеризованный индекс SQL Server не обязательно должен быть уникальным и не должен быть первичным ключом.

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

Исторически сложившиеся исторические версии SQL Server pre 6.5 или 7.0 IIRC не поддерживали блокировку на уровне строк и могли блокироваться только на уровне таблицы или страницы. Часто кластерный индекс будет использоваться для обеспечения того, чтобы записи были разбросаны по физическому хранилищу таблицы, чтобы свести к минимуму конфликт на блокировки страниц. Тем не менее, SQL Server 6 получил поддержку несколько лет назад, поэтому приложения с этой проблемой будут ограничены редкими устаревшими системами.