Индекс SQL Server 2000 - кластеризованный или некластеризованный

Question

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

т.е. IX_PrimaryKey - это кластеризованный индекс для идентификатора столбца. IX_ID является некластеризованным индексом для идентификатора столбца.

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

Кто-нибудь может подумать о выигрыше в производительности для этого?

Answer 1

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

Answer 2

Хранение двух индексов для одних и тех же данных - пустая трата дискового пространства и обработка, необходимая для обслуживания данных.

Однако я могу представить продукт, который зависит от наличия индекса с именем IX_PrimaryKey. Е.Г.

string queryPattern = "select * from {0} as t with (index(IX_PrimaryKey))";

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

Собирая все это вместе, я могу определенно подумать о сценариях, в которых удаление дублирующих индексов было бы плохим:

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

Я не рассматриваю ни один из этих хороших дизайнов, но я точно могу представить, что кто-то делает это. (Вы опубликовали это в DailyWTF?)

В некоторых случаях имеет смысл иметь перекрывающиеся индексы, которые не идентичны:

create index IX_1 on table1 (ID)
create index IX_2 on table1 (ID, TYPE, ORDER_DATE, TOTAL_CHARGES)

Если вы ищите строго по ID, SQL может оптимизировать и использовать IX_1. Если вы выполняете запрос на основе ID, TYPE, ORDER_DATE и суммируете TOTAL_CHARGES, SQL может использовать IX_2 в качестве «покрывающего индекса», удовлетворяя все детали запроса из индекса, даже не касаясь таблицы. Обычно это то, что вы добавляете в процессе настройки производительности после всестороннего тестирования.

Глядя на ваш приведенный пример двух индексов для одного и того же поля, я не вижу подходящего варианта. Возможно, SQL может использовать IX_ID в качестве «индекса покрытия» при проверке существования значения и обойти блокировку IX_PrimaryKey?

Answer 3

Создание кластерного первичного ключа будет пустой тратой. Если у вас нет запроса, который ищет записи, используя WHERE ID = 10?

Возможно, вы захотите создать кластерный индекс для столбца, который будет часто запрашиваться в WHERE City = 'Sydney'. Кластеризованный означает, что SQL будет группировать данные в таблице на основе кластеризованного индекса. Группировка значений City в таблице означает, что SQL может искать данные быстрее.

Answer 4

Я предполагаю, что произошло бы то, что SQL Server автоматически создал бы кластеризованный индекс, когда было указано ограничение первичного ключа (это произошло бы, если бы другой индекс (некластеризованный / кластеризованный) уже не присутствовал), а затем какой-то создали некластеризованный индекс для столбца первичного ключа.

Такой сценарий:

• Неблагоприятно влияет на производительность, так как индексы обновляются при вставках / удалениях / обновлениях.
• Использовать дополнительное дисковое пространство.
• Может привести к тупикам.
• Будет способствовать увеличению времени на резервное копирование / восстановление базы данных.

ура

Answer 5

Кажется, нет разумной причины для этого, и производительность снижается.

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

Вполне возможно, что первоначальный создатель не знал, что PK по умолчанию использовал кластеризованный индекс, и создал индекс NC, не осознавая, что это дубликат.

Answer 6

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

Копаясь в BOL и просматривая этот вопрос, хотя ...