Будет ли добавление кластерного индекса в существующую таблицу повысить производительность?

Question

У меня есть база данных SQL 2005, которую я унаследовал, с таблицей, которая выросла примерно до 17 миллионов записей в течение примерно 15 лет, и теперь она ужасно медленная.

Компоновка таблица выглядит примерно так:

id_column = nvarchar(20),indexed, not unique 
column2 = nvarchar(20), indexed, not unique 
column3 = nvarchar(10), indexed, not unique 
column4 = nvarchar(10), indexed, not unique 
column5 = numeric(8,0), indexed, not unique 
column6 = numeric(8,0), indexed, not unique 
column7 = nvarchar(20), indexed, not unique 
column8 = nvarchar(10), indexed, not unique 

(и около 5 более колонн, которые выглядят почти так же, не индексируются)

Поле «Идентификатор» является значение, введенное в конечным пользователем.

Нет первичных ключей и нет столбцов, которые могут быть объединены, чтобы создать уникальную строку (если все столбцы не объединены). Таблица фактически представляет собой таблицу «детали» для другой таблицы, но нет ограничений, обеспечивающих ссылочную целостность.

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

Сказав все это, мой вопрос: мог ли добавить кластеризованный индекс сделать мне что-нибудь полезное на данный момент?

Если бы я добавил кластерный индекс, я предполагаю, что это должен был быть новый столбец, т. Е. Столбец идентичности? В принципе, это стоит того?

Цените любой совет.

Answer 1

Я бы сказал, добавьте только кластеризованный индекс, если есть аргумент в пользу его использования. Поэтому задайте эти вопросы;

Имеет смысл порядок данных?

Есть ли последовательное значение способа ввода данных?

Должен ли я использовать функцию, которая требует наличия кластеризованного индекса, такого как полный текстовый индекс?

Если ответ на эти вопросы является «Нет», то кластерный индекс может не оказать никакой дополнительной помощи по хорошей некластеризованной стратегии индекса. Вместо этого вы можете подумать о том, как и когда вы обновляете статистику, когда вы обновляете индексы и анализируете ли отфильтрованные индексы в вашей ситуации. Глядя на таблицу, которую вы имеете в качестве примера, трудно сказать, но, возможно, имеет смысл нормализовать таблицу дальше и использовать числовые ключи вместо nvarchar.

http://www.mssqltips.com/sqlservertip/3041/when-sql-server-nonclustered-indexes-are-faster-than-clustered-indexes/ статья является отличным примером того, когда некластеризованные индексы могут иметь больше смысла.

Answer 2

Я бы рекомендовал добавить кластерный индекс, даже если это столбец идентификаторов по 3 причинам:

1. Предполагая, что существующие запросы должны пройти через весь стол каждый раз, clustered index scan is still faster than a table scan.

2. Таблица является ребенком для какой-либо другой таблицы. С некоторыми дополнительными работами вы можете использовать новый child_id, чтобы присоединиться к родительской таблице. Это позволяет искать кластерный индекс, который в некоторых случаях намного быстрее, чем сканирование.

3. В зависимости от того, как они настроены, существующие индексы могут не очень хорошо. Я столкнулся с некоторыми ужасными индексами, которые охватывают 1 столбец каждый или индексы, которые не включают соответствующие столбцы, что приводит к дорогостоящим операциям Key Lookups. Check your index stats, чтобы узнать, используются ли они вообще.