Некластеризованный индекс SQL Server 2008 содержит кластерные поля индексов?

Question

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

В SQL Server 2008 у меня есть «основная» таблица с около 50 тыс. Записей и много активности чтения, которая используется одинаково во всех запросах. Эти данные обновляются раз в месяц и читаются сотни раз в секунду.

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

кластерный индекс

Field1 int 
Field2 int 
Field3 int 
Field4 int 
Field5 int 

Теперь, есть не много больше данных, чем это, так что это будет иметь смысл только положить дополнительную пару колонок в «Включено Столбцы ", но SQL Server не позволяет включать столбцы в Clustered Index.

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

ПОКРЫТИЕ INDEX (некластерный)

Field1 int 
Field2 int 
Field3 int 
Field4 int 
Field5 int 

КОМПЛЕКТНОСТИ КОЛОННЫ

Field6 varchar(96) 
Field7 varchar(96) 

ли УЖЕ есть некластеризованный индекс столбцы из кластерного индекса, определенного в нем?

Если да, то каким образом этот второй индекс мог бы быть создан без столбцов NO (кроме того, что уже находится в кластерном индексе)? Другими словами, я хотел бы сказать: «Этот индекс точно такой же, как кластеризованный индекс ... с несколькими включенными столбцами».

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

Итак, существует ли эффективный способ настройки этих индексов, чтобы все столбцы этой таблицы были доступны через индекс, не возвращаясь к таблице?

Answer 1

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

Однако, если вы занимаете память, то вам нужно сжать стол. С 50k строк я бы подумал о маленьком суррогатном ключе, начиная с -32768. Затем вы удаляете служебные данные ключа C в каждом индексе NC. Это означает, что вы можете иметь индекс покрытия, как указано в вашем вопросе.

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

Однако, если ваши данные являются почти статическими, то зачем вообще вызывать SQL Server, если производительность является проблемой? Загрузите его. Удалите сеть в оба конца, что, вероятно, является вашим самым большим накладным капиталом, основанным на моих комментариях кэширования. Мы передаем некоторые запросы и кеширование нашим клиентам, чтобы уменьшить нагрузку на сервер (у нас есть 50 тыс. Записей примерно за 20 секунд при максимальной нагрузке)

Answer 2

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

Дополнительный индекс ЧПУ с 2 включенными полями может быть действительным, если этот индекс удовлетворяет большому количеству запросов, но я не уверен, что это решение правильной проблемы.

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

Это основная причина, по которой вы хотите, чтобы ваш кластерный ключ был как можно более узким, вы должны изучить кластерный ключ, как спросить, почему вы выбираете 5-ти кластеризованный ключ, и этот выбор приведет к фрагментации?

Возможно, вам будет лучше с искусственным значением (Identity) для кластерного ключа и используйте уникальный индекс NC, чтобы обеспечить уникальность, которую у вас есть, с 5-мя кластеризованными ключами.

Answer 3

это имело бы смысл просто поставить лишнюю пару колонн в «Включенные столбцы», но SQL Server не позволяет включены столбцы на кластерный индекс

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

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

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

ли Некластеризованный индекс УЖЕ есть столбцы из кластерного индекса, определенного в нем?

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

Итак, есть эффективный способ установить эти показатели, так что все столбцов этой таблицы доступны через индекс без Возвращение к столу?

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

Answer 4

Я думаю, вам нужно лучше понять CLUSTERED и NONCLUSTERED индексы. Кластеризованный индекс представляет собой сбалансированное дерево (B-tree), где каждый узел содержит ключевые столбцы (индексы) для индекса. Обычно, и часто лучший вариант, один столбец является ключевым столбцом для индекса. все данные для каждой строки хранятся на уровне листа (то есть нижнем уровне) кластерного индекса. Вот почему вы не можете включать столбцы в кластерный индекс; все столбцы включены по определению.

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

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

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