Причины не иметь кластерного индекса в SQL Server 2005

Question

Я унаследовал некоторые сценарии создания базы данных для базы данных SQL SERVER 2005.

Я заметил, что все первичные ключи создаются как индексы NON CLUSTERED, а не кластерные.

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

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

Answer 1

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

На вещи, такие как массовые таблицы импорта или временные таблицы - это зависит.

Для некоторых людей, похоже, что кластерный индекс может ускорить операции, такие как INSERT или UPDATE. См. Kimberly Tripps отличное сообщение The Clustered Index Debate continues...., в котором она подробно объясняет, почему это так.

В этом свете: Я не вижу какую-либо веской причины не иметь хороший кластерный индекс (узкий, стабильные, уникальные, постоянно увеличивающийся = INT IDENTITY как самые очевидный выбор) на любой таблице SQL Server ,

Чтобы получить некоторые глубокое понимание, как и почему, чтобы выбрать ключи кластеризации, прочитать все отличные посты в блоге Kimberly Tripp на тему:

http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustering-Key.aspx

http://www.sqlskills.com/BLOGS/KIMBERLY/category/Clustered-Index.aspx

Отличный материал от «Королева индексации "!:-)

Answer 2

Clustered Tables vs Heap Tables

(Хорошая статья по этому вопросу на www.mssqltips.com)

КУЧА Таблица (без кластерного индекса)

• данные не хранятся в какой-либо конкретной порядке

• Конкретные данные c не извлекаться быстро, если нет также некластеризованных индексов

• страницы данных не связана между собой, так последовательного доступа необходимо отсылает на карту распределения индекса (IAM) страницы

• Поскольку не существует кластерный индекс, дополнительное время не требуется, чтобы поддерживать индекс

• Поскольку нет кластерного индекса, там не й е необходимость дополнительного пространства для хранения кластерный индекс дереву

• Эти таблицы имеют index_id значение 0 в представлении каталога sys.indexes

Кластерный Таблица

• Данные хранятся в порядке, указанном на Кластеризованный ключевой ключ

• Данные могут быть получены быстро на основе на кластерном ключа индекса, если запрос использует индексированные столбцы

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

• дополнительное пространство, необходимое для хранения кластерный индекс дерево Эти таблицы имеют index_id значение 1 в каталоге sys.indexes view

Answer 3

Другой еще (есть ли в других ответах?) Возможная причина (по-прежнему следует понимать):

• SQL Server - Poor performance of PK delete

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

Обновление:
What do I miss in understanding the clustered index?

Answer 4

Пожалуйста, прочтите мой ответ в разделе «Нет прямого доступа к строке данных в кластерной таблице - почему?», первый. В частности, пункт [2] Предостережение.

Люди, создавшие «базу данных», являются кретинами. У них были:

• куча unnormalised spreadhseets, не нормированные реляционные таблицы
• ПКС является всех IDENTITY столбцов (электронные таблицы связаны друг с другом, они должны быть перемещаться один за один- одним); нет реляционной доступы или реляционной мощности по базе данных
• они имели PRIMARY KEY, которые производят UNIQUE кластерного
• они обнаружили, что это предотвратить параллелизм
• они удалили CI и сделали их все NCIS
• они были слишком ленив, чтобы закончить разворот; назначить альтернативный (текущий NCI), чтобы стать новым CI, для каждой таблицы
• столбец IDENTITY остается первичный ключ (это не очень, но именно в этом hamfisted реализации)

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

Если вам нужно обсудить этот ответ дальше, отправьте CREATE TABLE/INDEX DDL; в противном случае это анализирующий время академический аргумент.

Answer 5

С некоторыми серверами b/tree/языками программирования, которые все еще используются сегодня, для хранения данных используются фиксированные или переменные длины. Когда в файл (таблицу) добавляется новая запись/запись данных, запись добавляется (1) в конец файла (или заменяет удаленную запись), а (2) индексы сбалансированы. Когда данные хранятся таким образом, вам не нужно беспокоиться о производительности системы (насколько это делает сервер b-дерева для возврата указателя на первую запись данных). Время отклика выполняется только # узлами в ваших индексных файлах.

Когда вы используете SQL, вы, надеюсь, осознаете, что производительность системы должна учитываться всякий раз, когда вы пишете инструкцию SQL. Использование инструкции ORDER BY в столбце без индексации может привести систему к коленям. Использование кластерного индекса может привести к ненужной нагрузке на CPU. Это 21-й век, и мне жаль, что нам не нужно было думать о производительности системы при программировании в SQL, но мы все еще это делаем.

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

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