Кластерный первичный ключ в столбце с уникальным идентификатором в SQL Server

Question

Если столбец идентификатора в таблице является уникальным идентификатором (Guid), есть ли смысл создавать первичный ключ кластеризованный в столбце идентификатора?

Учитывая, что они глобально уникальны, как будет работать сортировка?

Answer 1

GUID, поскольку они ужасны для производительности, поскольку они являются фактически случайными значениями (это «разбивает» кластеризованный индекс), и они ужасны для индексов, поскольку на одной странице / экстенте помещается меньше записей (термины SQL Server). SQL Server 2005 представляет newsequentialid(), что помогает решить первую проблему.

Answer 2

Я настоятельно не рекомендую использовать кластерный ключ Guid ... У нас были большие проблемы с производительностью на сервере SQL из-за такого плохого дизайна несколько лет назад.

Также ознакомьтесь: Повышение производительности первичного ключа GUID индекса кластера

Answer 3

Размещение кластеризованного индекса в столбце guid не очень хорошая идея (если только вы не используете последовательные направляющие).

Кластерный индекс определяет физический порядок хранения записей.
Это означает, что если вы поместите кластерный индекс в столбец, который не будет последовательно расти, SQL Server придется поработать, чтобы убедиться, что записи правильно упорядочены физически при вставке новых записей.

Answer 4

Идея иметь отсортированный индекс сама по себе очень хороша, так как поиск становится очень эффективным.

Проблема, однако, состоит в том, что в случае GUID никто не ищет с "WHERE GUID = xyz". Таким образом, вся концепция впустую. Поэтому я бы посоветовал иметь кластеризованный индекс для столбца, который чаще всего используется в качестве SARG для повышения эффективности запросов.