Индекс SQL Server Какой кластер должен быть?

Question

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

Nonclustered
I3_Identity (bigint)
rows: 193,781
pages: 3821
MB: 29.85
user seeks: 463,355
user_scans: 784
user_lookups: 0
updates: 256,516

Clustered Primary Key
I3_RowId (varchar(80))
rows: 193,781
pages: 24,289
MB: 189.76
user_seeks: 2,473,413
user_scans: 958
user_lookups: 463,693
updates: 2,669,261

Как вы можете видеть, поиски PK часто производятся, но все запросы для столбца i3_identity также выполняют поиск ключей для этого PK, так что я действительно сильно выигрываю от индекса I3_Identity? Должен ли я перейти на использование I3_Identity в качестве кластерного? Это может оказать огромное влияние, так как эта структура таблицы повторяется около 10000 раз, когда я работаю, поэтому любая помощь будет оценена.

Answer 1

Фредерик хорошо подытоживает, и это действительно то, что проповедует Кимберли Трипп: ключ кластеризации должен быть стабильным (никогда не меняющимся), постоянно увеличивающимся (IDENTITY INT), небольшим и уникальным.

В вашем сценарии я бы предпочел поместить ключ кластеризации в столбец BIGINT, а не в столбец VARCHAR (80).

Прежде всего, с помощью столбца BIGINT довольно легко реализовать уникальность (если вы сами не применяете и не гарантируете уникальность, SQL Server добавит 4-байтовый «uniquefier» к каждой строке) и он НАМНОГО меньше в среднем, чем VARCHAR (80).

Почему размер так важен? Ключ кластеризации также будет добавлен в КАЖДЫЙ и каждый из ваших некластеризованных индексов - поэтому, если у вас много строк и много некластеризованных индексов, наличие 40-80 байт против 8 байт может быстро сделать ОГРОМНОЕ разница.

Кроме того, еще один совет по повышению производительности: во избежание так называемых поисков закладок (из значения в некластеризованном индексе через ключ кластеризации на страницы фактических данных) в SQL Server 2005 введено понятие « включенные столбцы "в ваших некластеризованных индексах. Это очень полезно, и часто упускается из виду. Если вашим запросам часто требуются поля индекса плюс только одно или два других поля из базы данных, рассмотрите возможность их включения, чтобы достичь того, что называется «покрывающими индексами». Опять же - посмотрите отличную статью Кимберли Трипп - она ​​богиня индексации SQL Server! :-) и она может объяснить это гораздо лучше, чем я ...

Итак, подведем итог: поместите ключ кластеризации в небольшой, стабильный, уникальный столбец - и у вас все будет хорошо!

Марк

Answer 2

быстрый и грязный:

Поместить кластерный индекс в:

• столбец, чьи значения (почти) никогда не меняются

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

• столбец, в котором вы выполняете диапазон - поиск

Answer 3

Вот лучшее обсуждение Я нашел по теме. Кимберли Трипп - блогер MS, который остается в центре дискуссии. Я мог бы истолковать это для вас, но вы, очевидно, не понимаете основных слов и понятий, и статья очень удобочитаема. Так что наслаждайтесь!

Подсказка: вы обнаружите, что короткие ответы почти всегда слишком упрощены.

Answer 4

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

Answer 5

Из того, что я читал в прошлом, две наиболее важные меры в отношении таблиц индексации - это количество запросов, выполненных к индексу, и плотность индекса. Используя DBCC_SHOWSTATISTICS ([таблица], [индекс]), вы можете проверить плотность индекса. Идея состоит в том, что вам нужен кластеризованный индекс для столбцов, которые обеспечивают наибольшую четкость для каждого запроса.

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

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

Редактировать: На MSDN есть довольно хорошая статья, в которой объясняется, что SHOW_STATISTICS предоставляет вам. Я, конечно, не администратор Uber, но большая часть информации, которую я здесь предоставил, основана на рекомендациях нашего администратора:)

Вот статья: http://msdn.microsoft.com/en-us/library/ms174384.aspx