Дилемма кластерного индекса - ID или сортировка?

Question

У меня есть таблица с двумя очень важными полями:

id INT identity(1,1) PRIMARY KEY
identifiersortcode VARCHAR(900)

Мое приложение всегда сортирует и отображает результаты поиска в пользовательском интерфейсе на основе identifiersortcode, но все объединения таблиц (и они легионы) находятся в поле id. (Помимо: да, код сортировки действительно такой длинный. Есть веская причина BL.)

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

В настоящее время кластеризованный индекс находится на id, но мне интересно, будет ли часть TOP / ORDER BY большинства запросов сделать identifiersortcode более привлекательным вариантом в качестве кластеризованного ключа, даже учитывая все объединения таблиц происходит.

Вставки в таблицу и изменения в identifiersortcode достаточно ограничены, чтобы изменение моего кластерного индекса могло стать проблемой для операций вставки / обновления.

Попытка сделать некластеризованный индекс кода сортировки индексом покрытия (используя INCLUDE) не является хорошим вариантом. Существует несколько больших столбцов, и некоторые из них активно обновляются.

Answer 1

Критерии Кимберли Л. Триппа для кластерного индекса таковы:

• Уникальная
• Узкое
• Статический
• постоянно увеличивается

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

Answer 2

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

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

Answer 3

В настоящее время кластеризованный индекс имеет идентификатор id, но мне интересно, сделает ли часть TOP / ORDER BY в большинстве запросов идентификационный код более привлекательным вариантом в качестве кластеризованного ключа, даже учитывая, что все объединения таблиц будут выполняться

Создание identifiersortcode a CLUSTERED KEY поможет только в том случае, если оно используется как в условиях фильтрации, так и в порядке упорядочения.

Это означает, что оно выбрано ведущей таблицей во всехВы присоединяетесь и используете Clustered Index Scan или Clustered Index Range Scan путь доступа.

В противном случае это только ухудшит ситуацию: во-первых, все вторичные индексы будут больше по размеру;во-вторых, вставки в не увеличивающемся порядке приведут к разбиению страницы, что заставит их работать дольше и приведет к увеличению таблицы.

Answer 4

Начните повторять то, что сказал Крис Б., я думаю, что вы действительно должны придерживаться своего текущего ПК, так как - как вы сказали - все объединения находятся на Ид. Я полагаю, вы уже проиндексировали код сортировки идентификаторов .... Тем не менее, если у вас есть проблемы с производительностью, вы бы дважды подумали об этом @ # "% $ £ identifiersortcode! -)

Answer 5

Почему, ради Бога, ваш код сортировки идентификаторов должен иметь длину 900 символов? Если вам действительно нужно 900 символов, чтобы их можно было различить для сортировки, вероятно, их следует разбить на несколько полей.