Использование некластеризованного индекса в столбце типа guid в SQL Server

Индекс на <anytype>, безусловно, лучший вариант для улучшения объединений и одноэлементного поиска. Без этого индекса запрос всегда должен будет сканировать всю таблицу от начала до конца с (часто) ужасными результатами производительности и параллелизмом.

Это правда, что uniqueidentifier плохо подходит для индексов по упомянутым вами причинам, но это никоим образом не означает, что вы не должны не создавать эти индексы. Если возможно, рекомендуется изменить тип данных на INT или BIGINT. Используя NEWSEQUENTIALID() или UuidCreateSequential для их создания поможет решить проблемы с фрагментацией. Если все альтернативы не работают, вам, возможно, придется выполнять операции обслуживания индекса (перестроение, реорганизация) чаще, чем для других индексов. Но ни один из этих недостатков ни в коем случае не перевешивает преимущества наличия индекса!

Два исполнения:
— вставить
— выбрать

Индекс должен улучшить выбор

Индекс замедляет вставку.
Если вставки упорядочены, индекс не фрагментируется.
Если вставки не упорядочены, индекс фрагментируется.
Фрагментация индекса замедляет как вставку, так и выборку.
Через обслуживание можно дефрагментировать индекс.

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

В самой таблице FK GUID не является хорошим кандидатом для PK (кластеризованного индекса).
С GUID в качестве PK, который индексирует фрагменты при вставке.
Int или последовательный идентификатор являются лучшими кандидатами, поскольку они не будут фрагментировать PK при вставке.
Но ничего страшного, просто дефрагментируйте эти таблицы.

Да, вам лучше изменить индекс Guid с кластерного на некластеризованный. Guid по-прежнему может быть первичным ключом, и вам не нужно менять свой запрос/исходный код. Отсутствие переупорядочения данных и повышение производительности.

В таких базах данных, как SQL Azure, наличие кластерного индекса обязательно. Таким образом, вы можете использовать поле даты/даты и времени. Создание дополнительного столбца int-identity/autoincrement не требуется, так как некоторые разработчики в одной команде склонны использовать те и другие GUID. Результат - несовместимое приложение. Так что держите только GUID.. точка!

Говоря о последовательных гидах, я думаю, что гиды лучше создавать из кода, чем из базы данных. Современные DAL и шаблоны репозиториев не предпочитают зависимости от БД для CRUD. например сценарий: запрос linq и автоматические сборки с модульным тестированием без зависимости от БД. И создавать последовательное руководство самостоятельно - не очень хорошая идея (по крайней мере, для меня). Таким образом, Guid в качестве первичного ключа с некластеризованным индексом — лучший вариант.

У меня есть поддержка от Microsoft по некластеризованной теме http://blogs.msdn.com/b/sqlazure/archive/2010/05/05/10007304.aspx

Отредактировано: поддержка исчезла ("Ресурс не найден")

Обычно это помогало производительности. Но вы можете захотеть создать индекс с коэффициентом заполнения менее 100%, чтобы не так часто приходилось сталкиваться с неизбежным разделением страниц. Регулярное обслуживание индекса, безусловно, будет плюсом.

Да, некластеризованный индекс был бы идеальным для вашей ситуации. Базовым является B-дерево, как и кластерный индекс, но базовые данные в таблице не отсортированы, поэтому проблем с непоследовательным характером GUID не существует. Индекс NC существует отдельно от таблицы.

Однако будьте осторожны, чтобы не добавить слишком много некластеризованных индексов. Оптимизируйте только там, где это необходимо. Запустите профилировщик, чтобы увидеть, какие запросы занимают много времени, и оптимизируйте только их. Кроме того, не забудьте установить коэффициент заполнения на значение ‹50%, если только база данных редко получает какие-либо обновления или пространство не является ограничением.

Соответствующий MSDN: http://msdn.microsoft.com/en-us/library/ms177484(v=sql.105).aspx