Разница между кластеризованным и некластеризованным индексом [дубликат]


этот вопрос уже есть ответ здесь:

  • Каковы различия между кластеризованным и некластеризованным индексом? 10 ответов

мне нужно добавить правильное index к моим таблицам и нужна помощь.

Я запутался и нужно уточнить несколько моментов:

  • Я должен использовать индекс для non-int колонны? Почему бы и нет

  • Я много читал о clustered и но я все еще не могу решить, когда использовать один над другим. Хороший пример поможет мне и многим другим разработчикам.

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

6 124

6 ответов:

вы действительно должны держать два вопроса друг от друга:

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

2) кластеризации ключ (столбец или столбцы, которые определяют "кластеризованный индекс" на стол) - это физическая связанная с хранением вещь, и здесь, небольшой, стабильный, постоянно увеличивающийся тип данных - ваш лучший выбор-INT или BIGINT в качестве опции по умолчанию.

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

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

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

Марк

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

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

вы должны использовать индексы для повышения производительности SQL server. Обычно это означает, что столбцы, которые используются для поиска строк в таблице индексируются.

кластеризованные индексы заставляют SQL server упорядочивать строки на диске в соответствии с порядком индексов. Это означает, что если вы обращаетесь к данным в порядке кластеризованного индекса, то данные будут присутствовать на диске в правильном порядке. Однако если столбцы с кластеризованным индексом часто изменяются, то строки будут перемещаться вокруг на диске, вызывая накладные расходы-что вообще не очень хорошая идея.

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

большинство типов данных столбцов можно использовать при индексации, но лучше иметь индексированные небольшие столбцы, чем большие. Также принято создавать индексы по группам столбцов (например, Страна + город + улица).

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

сравнение некластеризованного индекса с кластеризованным индексом на примере

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

EmployeeID

и указатель на строку в таблице employee, где это значение хранится. Но кластеризованный индекс, с другой стороны, будет фактически хранить данные строки для конкретного EmployeeID-так что если вы выполняете запрос, который ищет EmployeeID 15, данные из других столбцов в таблице, как

EmployeeName, EmployeeAddress, etc

. все они будут фактически храниться в конечном узле самого кластеризованного индекса.

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

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

SELECT * FROM FOO WHERE FOO.BAR = 2

вы, возможно, захотите, чтобы положить индекс на ФОО.БАР. Кластеризованный индекс должен использоваться для столбца, который будет использоваться для сортировки. Кластерный индекс используется для сортировки строк на диске, так что вы можете иметь только один на таблицу. Например, если у вас есть запрос

SELECT * FROM FOO ORDER BY FOO.BAR ASCENDING

вы можете рассмотреть кластеризованный индекс на FOO.БАР.

вероятно, наиболее важным соображением является то, сколько времени занимают ваши запросы. Если запрос не занимает много времени или используется не очень часто, возможно, не стоит добавлять индексы. Как всегда, сначала профиль, потом оптимизация. SQL Server Studio может дать вам предложения о том, где оптимизировать, и MSDN имеет некоторую информацию1 что вы могли бы найти полезным

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

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