Не на 100% уверен в том, что вы ожидаете услышать - у вас может быть только один кластеризованный индекс в таблице, и по умолчанию каждая таблица (за очень небольшим исключением исключительных ситуаций) должна иметь один. Все индексы, как правило, больше всего помогают вашим SELECT, а некоторые, как правило, немного повреждают INSERT, DELETE и, возможно, UPDATE (или много, если они выбраны неправильно).
Кластерный индекс делает таблицу быстрее для каждой операции. ДА! Оно делает. См. Превосходную Ким Трипп * Дебаты по кластерным индексам продолжаются для получения дополнительной информации. Она также упоминает свои основные критерии для кластерного индекса:
- узкая
- статический (никогда не меняется)
- уникальный
- если возможно: постоянно увеличивается
INT IDENTITY отлично справляется с этой задачей, а GUID - нет. См. GUID в качестве первичного ключа для получения дополнительной информации.
Почему сужается? Поскольку ключ кластеризации добавляется к каждой странице индекса каждого и каждого некластеризованного индекса в одной и той же таблице (для того, чтобы иметь возможность фактически искать строку данных, если нужно). Вы не хотите иметь VARCHAR (200) в своем ключе кластеризации ....
Почему уникален ?? См. Выше - ключ кластеризации - это элемент и механизм, который SQL Server использует для уникального поиска строки данных. Это должно быть уникальным. Если вы выберете неуникальный ключ кластеризации, SQL Server сам добавит 4-байтовый уникализатор к вашим ключам. Будьте осторожны с этим!
Далее: некластеризованные индексы. В основном есть одно правило: любой внешний ключ в дочерней таблице, ссылающейся на другую таблицу, должен быть проиндексирован, это ускорит JOIN и другие операции.
Кроме того, любые запросы с предложениями WHERE являются хорошим кандидатом - выберите те, которые выполняются первыми. Поместите индексы в столбцы, которые отображаются в предложениях WHERE, в операторах ORDER BY.
Далее: измерьте свою систему, проверьте DMV (динамические административные представления) на наличие подсказок о неиспользуемых или отсутствующих индексах и настраивайте свою систему снова и снова. Это непрерывный процесс, вы никогда не закончите!
Еще одно предупреждение: при большом количестве индексов вы можете сделать любой запрос SELECT действительно очень быстрым. Но в то же время могут пострадать ВСТАВКИ, ОБНОВЛЕНИЯ и УДАЛЕНИЯ, которые должны обновлять все задействованные индексы. Если вы только выбираете - сходите с ума! В противном случае, это прекрасный и тонкий баланс. Вы всегда можете изменить один запрос до предела, но остальная часть вашей системы может пострадать от этого. Не переиндексировать вашу базу данных! Поместите несколько хороших показателей на место, проверьте и посмотрите, как работает система, а затем, возможно, добавьте еще один или два, и снова: посмотрите, как это влияет на общую производительность системы.