#sql #sql-server #sql-server-2008 #indexing
#sql #sql-сервер #sql-server-2008 #индексирование
Вопрос:
Если разрешено создавать 249 некластеризованных индексов в таблице, означает ли это, что безопасно иметь некластеризованный индекс в каждом столбце? Каков будет эффект от этого? Или мы должны выбрать только некоторые столбцы, чтобы создать некластеризованный индекс.
Это:
create nonclustered index ix_test(col1, col2, col3)
Отличается от этого: ?
create nonclustered index ix_test(col1)
create nonclustered index ix_test2(col2)
create nonclustered index ix_test3(col3)
Ответ №1:
Индексы хороши для чтения и плохи для записи.
Когда вы только читаете данные, индексы могут помочь быстрее находить данные и ускорить чтение.
С другой стороны
При записи данных (ОБНОВЛЕНИЕ / УДАЛЕНИЕ / ВСТАВКА) sql server придется записывать данные дважды: один раз на страницах SQL Server, где хранятся фактические данные, и один раз для индексов. что приведет к более медленной записи.
Вам нужно будет найти ту золотую середину, где ваши чтения не страдают от недостатка вспомогательных индексов, а ваши записи не страдают от слишком большого количества индексов.
Приведенное выше утверждение верно для приложений OLTP, где данные меняются довольно часто, но если это данные OLAP / хранилища данных, которые практически не меняются, если вообще меняются, вы можете добавить столько индексов, сколько требуется для чтения, чтобы повысить производительность. Надеюсь, это поможет.
Комментарии:
1. Вот почему unique/ guid являются хорошим кандидатом для индекса, потому что они не меняются.
2. Я думаю, вы хотели сказать, что guid является хорошим кандидатом для кластеризованного индекса, а это не так. Значение идентификатора является гораздо лучшим кандидатом для кластеризованного индекса.
3. Неиспользуемые и избыточные индексы занимают место в дополнение к дополнительным затратам на обслуживание. Сложные запросы, наряду с большим количеством индексов, могут привести к более длительному времени компиляции, чем необходимо, а иногда и к неоптимальным планам.