SQL Server 2000 Index - Clustered vs Non Clustered

Question

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

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

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

Может ли кто-нибудь подумать об эффективности работы для этого?

Answer 1

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

Answer 2

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

Рытье через BOL и смотреть на этот вопрос, хотя ...

Answer 3

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

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

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

Answer 4

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

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

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

веселит

Answer 5

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

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

Answer 6

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

Однако я могу представить себе продукт, который зависит от наличия индекса с именем IX_PrimaryKey. НАПРИМЕР.

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

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

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

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

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

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

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

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

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