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

Какой тип индекса (кластерный / некластеризованный) следует использовать для оператора Insert / Update / Delete в SQL Server. Я знаю, что это создает дополнительные накладные расходы, но лучше ли он по производительности по сравнению с некластеризованным индексом? Также какой индекс следует использовать для операторов Select в SQL Server?


database sql-server performance indexing database-indexes
person Charu    schedule 23.04.2010    source источник
comment
Вы читали этот вопрос: stackoverflow.com/questions/91688/?   -  person Jørn Schou-Rode    schedule 24.04.2010

Ответы (2)


arrow_upward
7
arrow_downward

Не уверен на 100%, что вы ожидаете услышать - у вас может быть только один индекс кластеризации в таблице, и по умолчанию каждая таблица (с очень немногими исключениями крайних случаев) должна иметь один. Все индексы обычно помогают вашим SELECT больше всего, а некоторые имеют тенденцию повредить INSERT, DELETE и, возможно, UPDATE, немного (или много, если выбран плохо).

Кластерный индекс ускоряет работу таблицы при каждой операции. ДА! Оно делает. См. Превосходный Ким Трипп. Дебаты по кластеризованному индексу продолжаются для справочной информации. Она также упоминает свои основные критерии кластерного индекса:

  • узкий
  • статический (никогда не меняется)
  • уникальный
  • если когда-либо возможно: когда-либо увеличивается

INT IDENTITY отлично справляется с этим, а GUID - нет. См. основные идентификаторы GUID Ключ для получения обширной справочной информации.

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

Почему уникальный? См. выше. Ключ кластеризации - это элемент и механизм, которые SQL Server использует для однозначного поиска строки данных. Он должен быть уникальным. Если вы выберете неуникальный ключ кластеризации, SQL Server сам добавит к вашим ключам 4-байтовый уникальный определитель. Остерегайтесь этого!

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

Кроме того, любые запросы, содержащие предложения WHERE, являются хорошим кандидатом - сначала выберите те, которые выполняются часто. Поместите индексы в столбцы, которые отображаются в предложениях WHERE, в операторах ORDER BY.

Далее: измерьте свою систему, проверьте DMV (динамические представления управления) на предмет подсказок о неиспользуемых или отсутствующих индексах и снова и снова настраивайте свою систему. Это непрерывный процесс, вы никогда не закончите!

Еще одно предупреждение: при большом количестве индексов любой запрос SELECT может выполняться очень быстро. Но в то же время могут пострадать операции INSERT, UPDATE и DELETE, которые должны обновлять все задействованные индексы. Если вы только когда-либо ВЫБИРАЕТЕ - сходите с ума! В противном случае это прекрасный и тонкий баланс. Вы всегда можете настроить один-единственный запрос невероятно, но остальная часть вашей системы может пострадать при этом. Не чрезмерно индексируйте свою базу данных! Установите несколько хороших индексов, проверьте и понаблюдайте за тем, как ведет себя система, а затем, возможно, добавьте еще один или два, и снова: понаблюдайте, как это влияет на общую производительность системы.

person marc_s    schedule 23.04.2010

arrow_upward
3
arrow_downward

Я не совсем уверен, что вы имеете в виду под «следует использовать для оператора Insert / Update / Delete», но, на мой взгляд, каждая таблица должна иметь кластерный индекс. Кластерный индекс определяет порядок, в котором данные фактически хранятся. Если кластеризованный индекс не определен, данные будут просто храниться в куче. Если у вас нет естественного столбца для использования в качестве кластерного индекса, вы всегда можете просто создать столбец идентификаторов как int или bigint, как это.

CREATE TABLE [dbo].[demo](
[ID] [int] IDENTITY(1,1) NOT NULL,
[FirstName] [nchar](10) NULL,
[LastName] [nchar](10) NULL,
[Job] [nchar](10) NULL,
 CONSTRAINT [PK_demo] PRIMARY KEY CLUSTERED 
(
[ID] ASC
))
person etoisarobot    schedule 23.04.2010