Каким должен быть мой кластерный индекс при использовании NEWSEQUENTIALID () в качестве первичного ключа?

Question

Я использую newsequentialid для генерации идентификаторов GUID для моего первичного ключа в таблице.

Согласно документации (https://docs.microsoft.com/en-us/sql/t-sql/functions/newsequentialid-transact-sql?view=sql-server-ver15), создание последовательных GUID не гарантируется по порядку.

После перезапуска Windows GUID может снова начаться с более низкого диапазона, но по-прежнему уникален в глобальном масштабе

В основном они в порядке до вы перезагружаете машину.

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

Для первичного ключа GUID это не делает смысл в том, что это кластеризованный индекс, потому что он случайный, маловероятно, что вставленная строка будет в конце.

А как насчет последовательного первичного ключа GUID? Должен ли первичный ключ быть кластеризованным индексом или я должен попытаться найти другой столбец, например поле DateCreated? Проблема в том, что такие поля, как DateCreated, не будут уникальными. Если у меня нет полей, которые являются уникальными полями, что мне делать в качестве кластеризованного индекса?

Answer 1

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

Тем не менее, первичный ключ не обязательно должен быть ключом кластеризованного индекса. У вас может быть столбец identity или дата / время создания в качестве кластеризованного индекса, что в значительной степени устраняет эту проблему.

Answer 2

Я написал об этом длинный пост go. TL / DR заключается в том, что использование последовательного GUID в качестве ключа кластеризованного индекса нормально. Идентификаторы GUID фактически вставляются в середину индекса, но наличие небольшого числа (здесь одна) точки вставки в середине индекса не вызывает дорогостоящих разделений страниц и не ведет к вредоносной фрагментации.

Хорошие разделения страниц и последовательное создание ключа GUID

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