Изменение индексации для существующей таблицы в SQL Server 2000

Question

Вот сценарий:

SQL Server 2000 (8.0.2055)

Таблица в настоящее время содержит 478 миллионов строк данных. Столбец Первичный ключ представляет собой INT с IDENTITY. Существует уникальное ограничение, накладываемое на два других столбца с некластеризованным индексом. Это приложение поставщика, и мы несем ответственность только за ведение БД.

Теперь поставщик рекомендовал сделать следующее «для повышения производительности»

1. Удалите PK и кластерный индекс
2. Удалите некластеризованный индекс для двух столбцов с помощью УНИКАЛЬНОГО ОГРАНИЧЕНИЯ
3. Воссоздать ПК с некластеризованным индексом
4. Создать индекс CLUSTERED для двух столбцов с УНИКАЛЬНЫМ ОГРАНИЧЕНИЕМ

Я не уверен, что это правильно. У меня есть ряд проблем.

Удалив PK и индексы, вы создадите кучу с 478 миллионами строк данных. Тогда создание КЛАСТЕРНОГО ИНДЕКСА на двух столбцах было бы действительно гигантской задачей. Было бы лучше создать другую таблицу с такой же структурой и новой схемой индексации, а затем скопировать данные, отбросить старую таблицу и переименовать новую?

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

Я просто не могу понять, какое "улучшение производительности" обеспечит это изменение. Я думаю, что это будет иметь обратный эффект.

Все мысли приветствуются.

Заранее спасибо,

Raj

Answer 1

Единственное, на что я бы серьезно посмотрел, - это на вопрос, к какому типу относятся эти два других столбца - насколько они велики по сравнению с INT IDENTITY (4 байта) ??

Причина, по которой я спрашиваю: ключ кластеризации будет добавлен также ко всем некластеризованным индексам в таблице - и если у вас будет около 500 миллионов строк, это сделает огромным разница , является ли ключ кластеризации одиночным 4-байтовым INT или, например, два 16-байтовых GUID.

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

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

Answer 2

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

В какой-то момент вам нужно реорганизовать 478 миллионов строк (удалить / создать индексы) или переместить (новая таблица). К сожалению, ни один из способов не лучше другого. Я чувствую вашу боль, хотя: у нас есть такие же большие таблицы с ожидающими новых столбцов и изменения индекса.

Сказав это, вы должны сделать это шаг 2-1-4-3, чтобы избежать ненужного обслуживания некластеризованного индекса при удалении / создании кластерного индекса.

И отбросьте уникальное ограничение. Кластерный индекс может быть уникальным и кластеризованным. Уникальное ограничение - это просто еще один индекс, который не нужен.

Что касается повышения производительности, возможно, спросите поставщика, почему.

Answer 3

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

Я считаю, что это то, что SQL Enterprise Manager будет делать негласно в любом случае, если вы будете использовать визуальные инструменты для этого. Если вы вносите изменения в схему, например добавляете столбец в середине таблицы или меняете первичные ключи, есть небольшая кнопка, которая позволит вам «Изменения в скрипте». Если вы просмотрите этот скрипт, вы увидите шаги, которые предпримет Enterprise Manager, чтобы выполнить то, что вы просили.