Индекс на Varchar?

Question

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

В данный момент в этом столбце МНОЖЕСТВО значений NULL. Однако со временем (эта таблица была запущена недавно), таблица значительно вырастет. В этот раз больше значения NULL не будут добавлены.

У меня вопрос в два раза. Во-первых, будет ли индекс здесь полезным? Процесс активно используется. И если так, должно ли оно быть кластерным или нет? Данные такие вещи, как CP123456, DR126512.

Второй вопрос, который, вероятно, влияет на первый вопрос, - было бы полезно изменить столбец на CHAR (10), так как «кажется», что номер заказа всегда одинакового размера. Есть ли какое-то преимущество в скорости при наложении индекса на символ CHAR фиксированной длины, в отличие от VARCHAR (150)?

(различается по размеру из-за неизвестных требований при создании столбца).

SQL Server 2008.

Answer 1

1. Да, абсолютно!Идите прямо вперед и добавьте индекс.Кластеризация индекса, вероятно, здесь не нужна и в любом случае будет невозможна, если у вас уже есть другой кластеризованный индекс (например, первичный ключ) в таблице.

2. Изменение столбца на CHAR(10) может иметь некоторые преимущества с точки зрения размера хранилища, но вряд ли это особенно сильно повлияет на производительность индекса.Я бы пропустил это сейчас.

Answer 2

У меня нет упоминаний об этом, только опыт / неподтвержденные данные.

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

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

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

Короче, определенно индексируйте свои данные. И кластерный индекс обычно лучше всего подходит для обслуживания ваших худших запросов.

Что касается разницы между VARCHAR и CHAR? В прежние времена было важно хранить поля переменной длины в конце ваших данных, чтобы было легче идентифицировать поля фиксированной длины. Это означало, что иметь поле VARCHAR в качестве первого поля и использовать его в качестве уникального идентификатора было довольно плохо.

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