Производительность вставки кластерного индекса по не столь уникальному столбцу

Question

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

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

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

Answer 1

Вы всегда должны стараться, чтобы ваши кластерные индексы были уникальными. Для таблиц с множеством вставок что-то наподобие int-идентификации является хорошим выбором, поскольку вставляемая страница часто находится в памяти, что уменьшает доступ к диску.

Если вы не сделаете свой кластеризованный индекс уникальным, SQL-сервер сделает это за вас, потому что он все еще должен иметь возможность каким-то образом находить определенные строки. Поддержание Uniquifier будет стоить что-то.

Так что, если вы хотите, чтобы кластеризованный индекс в таблице комментариев был идентификатором поста? Это может быть полезно, потому что поиск всех комментариев к сообщению становится очень быстрым, вся информация находится в той же области на диске.

Нет проблем, сделайте индекс уникальным, добавив в него больше столбцов: Например:

create unique clustered index pk_comment(post_id, comment_id)  

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

Итак, я бы порекомендовал сделать это простым и просто добавить первичный ключ на comment_id, а затем профилировать добавление приложения в покрытых индексах по мере необходимости. Только если основной способ размещения данных на диске становится проблемой, вам следует подумать о усложнении.

Answer 2

Зависит от:

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

Тебе следует ориентироваться в конкретной ситуации.