Назад | Перейти на главную страницу

Изменение поля кластеризованного индекса MSSQL со «случайных» GUID на последовательные GUID - как это повлияет на индексы

У нас есть база данных MSSQL, в которой все первичные ключи - это идентификаторы GUID (уникальные идентификаторы). Идентификаторы GUID создаются на клиенте (в C #), и мы рассматриваем возможность изменения клиента для генерации последовательных (гребенчатых) идентификаторов GUID вместо простого использования Guid.NewGuid () для повышения производительности базы данных.

Если мы это сделаем, как это повлияет на установки, в которых уже есть данные со «случайными» идентификаторами GUID в качестве кластерных PK? Можно ли что-нибудь сделать (кроме изменения всех значений PK) для восстановления индексов, чтобы избежать дальнейшей фрагментации и плохой производительности вставки?

Пожалуйста, дайте ясные и подробные ответы, если можете; В душе я разработчик C # и не слишком знаком со всеми тонкостями SQL Server.

Спасибо!

Быстрый комментарий: GUID + кластерный индекс? Звучит плохо - кластеризованный индекс означает, что таблица физически находится на диске в порядке индекса, поэтому вставка потенциально должна переписывать страницы базы данных, чтобы они были в порядке. Измените его на некластеризованный индекс, и производительность улучшится.

Последовательные GUID имеют множество проблем, они действительно не гарантируют уникальность, если они последовательны, где-то, если вы масштабируете кусок для работы в нескольких местах, последовательность потенциально дублируется.

Попробуйте отбросить кластерный индекс и создать тот же некластерный индекс - вы почти наверняка устраните любые проблемы - случайный GUID НЕ проблема с производительностью, Guid.NewGuid не требует времени (МНОЖЕСТВО других вещей замедлится до того, как эта процедура станет проблемой).

Кластерные индексы подходят не для всего.