Как узнать, когда использовать индексы и какой тип?

Question

Я немного искал и не видел ни одного подобного вопроса, так что здесь.

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

Может ли индекс когда-нибудь замедлить выполнение операторов select? Сколько индексов - это слишком много, и какой размер таблицы вам нужен, чтобы индекс извлекал пользу из индекса?

EDIT:

А как насчет типов данных столбцов? Можно ли иметь индекс для varchar или datetime?

Answer 1

Ну, первый вопрос прост:

Когда следует использовать кластерный индекс?

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

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

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

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

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

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

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

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

Еще одно предупреждение: благодаря большому количеству индексов вы можете сделать любой запрос SELECT действительно очень быстрым. Но в то же время могут пострадать ВСТАВКИ, ОБНОВЛЕНИЯ и УДАЛЕНИЯ, которые должны обновлять все задействованные индексы. Если вы только выбираете - сходите с ума! В противном случае, это прекрасный и тонкий баланс. Вы всегда можете изменить один запрос до предела, но остальная часть вашей системы может пострадать от этого. Не переиндексировать вашу базу данных! Поместите несколько хороших показателей на место, проверьте и посмотрите, как работает система, а затем, возможно, добавьте еще один или два, и снова: посмотрите, как это влияет на общую производительность системы.

Answer 2

Отвечая на те, которые я могу, я бы сказал, что каждая таблица, независимо от ее размера, всегда будет извлекать выгоду как минимум из одного индекса, поскольку должен быть хотя бы один способ, которым вы заинтересованы в поиске данных; иначе зачем хранить?

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

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

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

Answer 3

Основное правило - это первичный ключ (подразумеваемый и по умолчанию кластеризованный) и каждый столбец внешнего ключа

Существует больше, но вы могли бы сделать хуже, чем использовать отсутствующий индекс SQL Server DMVs

Индекс может замедлять SELECT, если оптимизатор делает неправильный выбор, и их может быть слишком много. Слишком много замедлит запись, но также возможно перекрытие индексов

Answer 4

Вы должны использовать индекс для столбцов, которые вы используете для выбора и упорядочения - то есть, предложения WHERE и ORDER BY.

Индексы могут замедлять операторы select, если их много, и вы используете WHERE и ORDER BY для столбцов, которые не были проиндексированы.

Что касается размера таблицы - несколько тысяч строк и более начнут показывать реальные преимущества использования индекса.

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

Answer 5

Если вы запрашиваете на основе значения в столбце, вы, вероятно, хотите индексировать этот столбец.

т.е.

SELECT a,b,c FROM MyTable WHERE x = 1

Вы хотите индекс на X.

Обычно я добавляю индексы для часто запрашиваемых столбцов и добавляю составные индексы, когда запрашиваю более одного столбца.

Индексы не повредят производительности SELECT, но они могут замедлить INSERTS (или UPDATES), если у вас слишком много столбцов индексов в таблице.

Как правило, начните с добавления индексов, когда вы говорите, ГДЕ a = 123 (в данном случае индекс для "a").

Answer 6

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